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Power Factor: 

Non-Linear 

Loads and the 

Power 

Distribution 

System 

Roger Cox 
IBM Corporation 
Boca Raton } Florida 

Power management is commonly 
a major concern to companies in¬ 
stalling large numbers of personal 
computers. This article discusses 
problems that may be encoun¬ 
tered after installation. 

One of the major issues with power 
electronics today is how harmonic 
currents are generated by the 
non-linear load of Switch Mode 
Power Supplies (SMPS) used in 
PS/2® computers and other 
non-linear load products. 

The effect of a non-linear load from 
a single SMPS or other non-linear 
load is usually of little consequence 
to a home or office installation or to 
the utility power distribution system. 
When non-linear loads become an 
appreciable portion of the load on a 
three-phase distribution transformer, 
problems can occur. When a busi¬ 
ness wants to install hundreds or 
thousands of PS/2s in its office build¬ 
ing along with the other non-linear 
loads, various forms of overloading 
can occur. The following overview 


discusses the problems and some 
possible solutions. 

What Are Non-Linear 
Loads? 

Maybe the easiest way to explain a 
non-linear load is to describe what a 
linear load is. A linear load produces 
a current that is directly proportional 


to the line voltage. For alternating 
current, the current increases or de¬ 
creases proportionately as the volt¬ 
age increases or decreases. This 
current can be in-phase or out-of- 
phase, which are discussed later, but 
in either event, the sine wave of volt¬ 
age produces a sine wave of current 
of the same frequency. 
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A non-linear load produces a current 
that is not directly proportional to 
the line voltage and is not a sine 
wave of the same frequency. Often 
the current is not continuous and can 
be switched on for only part of the 
cycle. 

A simple comparison helps illustrate 
the difference between the two. A 
non-linear load can be compared to 
a linear load like a fluorescent bulb 
to an incandescent light bulb. The 
major difference between the two is 
that the fluorescent bulb’s current 
pulsates not directly proportional to 
the voltage, and the incandescent 
bulb’s current varies directly propor¬ 
tional to line voltage. 

AC Power Terminology 

There are a large number of single¬ 
phase, two-phase, and three-phase 
power distribution systems through¬ 
out the world. Single-phase stands 
by itself, even though it could be 
supplied from any of the three sys¬ 
tems just mentioned; that is, it could 
be line-to-neutral (L-N) from a three- 
phase system, and so on. There are 
numerous grounding schemes used 
around the world; for example, 
grounded wye; corner grounded 
delta; tap-grounded delta; floating 
wye, delta, and tee; impedance 
grounded wye; and grounded open 
delta. This discussion is limited to 
the wye configuration for three- 
phase systems, and the content is in¬ 
dependent of the grounding scheme. 
Although U.S. voltages may be dis¬ 
cussed, the general principle applies 
to all countries and voltages. 

Single-Phase Systems: Single¬ 
phase sinusoidal (sine wave) 50 or 
60 Hz is the power supplied to all 
PC-type products. The voltage wave¬ 
form provided by the utility com¬ 
pany is a sine wave, which is 
usually of good quality, and it main¬ 
tains its waveshape. The shape of 


the current waveform is entirely a 
function of the load. A resistive-type 
load provides a sine wave of current 
that is in phase with the voltage sine 
wave. The term in phase means that 
corresponding points of the voltage 
and current waveshapes occur at the 
same time on the time scale: posi¬ 
tive peaks, negative peaks, as well 
as positive and negative zero cross¬ 
overs. An inductive or capacitive 
load also provides a sine wave of 
current, but it it is lagging or leading 
with respect to the voltage. They are 
not in phase and are called, of 
course, out of phase. Any combina¬ 
tion of resistive-, inductive-, and ca¬ 
pacitive-type loads always provides 
a sine wave of current and the loads 
are considered linear loads. 

Three-Phase Systems: A three- 
phase system is just three single¬ 
phase systems that are displaced in 
time phase from one another. The 
time displacement between phases is 
one-third of a cycle or 120 degrees 
of a complete cycle of 360 degrees. 
The discussion of the sine wave cur¬ 
rent that could be lagging or leading 
or in phase applies equally to the 
three-phase system. In building dis¬ 
tributions, the wye connection is 
usually used for the transformer sec¬ 
ondary that uses four-wire distribu¬ 
tion: line 1, line 2, line 3, and 
neutral. The single-phase voltage is 
measured from any one of the lines 
to neutral. 

The neutral in the three-phase sys¬ 
tem is the common point and the re¬ 
turn for the three phases. It conducts 
the total return current for the three 
phases. An interesting fact in three- 
phase theory is that the neutral cur¬ 
rent in a balanced linear load system 
is zero. Even though each phase has 
a return current, the addition of three 
equal currents, each 120 degrees 
apart, makes the return current zero. 
That is why building wiring used to 


allow the neutrals to be wired at a 
50 percent reduction in current carry¬ 
ing capacity. This is the root of the 
problem associated with building 
wiring, which is discussed later. 

Power and Volt-Amperes: Power 
is measured by a wattmeter and rep¬ 
resents the amount of work being 
done (or heat generated). In power 
distribution books, the terms real 
power and reactive power are used. 
Real power represents the amount of 
work being done, is generally re¬ 
ferred to as simply power in the 
computer industry, and is measured 
by watts. Reactive power is really a 
misnomer because is not power. It 
does not represent any work being 
done and does not contribute to the 
watts measured by a watt meter. 

This reactive power comes from the 
inductive and capacitive loads that 
produce the out-of-phase currents 
mentioned previously. 

The term volt-amperes is the product 
of the voltage and the current being 
measured. It is a combination of the 
real power and the reactive power. It 
is called volt-amperes to distinguish 
it from the real or the reactive pow¬ 
ers. Because it is a combination of 
the real and reactive power, it has a 
larger value than either. Present-day 
watt meters give readouts of the to¬ 
tal current and the voltage as well as 
the watts. Multiplying the total cur¬ 
rent and the voltage gives you the 
volt-amperes. 

Power Factor: Power factor is de¬ 
fined two different ways today, de¬ 
pending on the type of load. The 
traditional definition is concerned 
with the sine wave of voltage and 
the sine wave of current. When an 
inductive or capacitive load pro¬ 
duces a load current that is displaced 
in time from the line voltage, the co¬ 
sine of the angle of displacement is 
defined as the power factor. When 
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the equations are worked out, power 
factor is also the power (watts) di¬ 
vided by the volt-amperes (VA). 

P.F. - Cos Angle = Power/Volt- 
Amperes 

For non-linear loads, which were de¬ 
fined in the section “What Are Non- 
Linear Loads?” there is no single 
“angle of displacement” that can be 
used to represent the power factor. 
The second half of the previous 
equation is what is used for 
non-linear load power factor, 
power/volt-amperes. 

Average Root-Mean-Square 
(RMS), Peak RMS, and True 
RMS Measurements: Many meas¬ 
urement techniques assume that the 
voltage and current waveforms are 
approximately sinusoidal. When this 
is not true, as in the case of non-lin¬ 
ear loads, errors result from the 
measurements. There are three com¬ 
mon measurement techniques used 
for AC voltages and currents: aver¬ 
age RMS, peak RMS, and true RMS. 

The average RMS measures average 
voltage and current over one half cy¬ 
cle, then converts the measurement 
(1.11 X average) to be repre¬ 
sentative for a sine wave because 
that is what is normally encountered. 
Most inexpensive digital voltmeters 
use average conversion because it is 
the least expensive to implement. It 
is also the approach used in older- 
style analog meters. 

The peak RMS measures the peak 
voltage and current over one cycle 
and then converts the measurement 
(0.707 X peak) to be representative 
for a sine wave because that is what 
is normally encountered. As the 
RMS indicates, the average RMS 
and peak RMS are calibrated to 
equal true RMS on sine waves. 


Waveform Description 

Average RMS 

Peak RMS 

True RMS 

Sine Wave 

100.0A 

100.0 A 

100.0A 

Square Wave 

100.0A 

63.6A 

90.0A 

Triangle Wave 

100.0A 

125.7A 

103.3A 

Non-Linear Load 

100.0 A 

400.1 A 

199.4A 


Figure 1. Voltage, Current, P.F., and Spectrum Measurements on Non-Sinusoidal AC 
Power Circuits (Reference 1) 


The RMS value of an AC waveform 
(voltage or current) is equivalent to 
the DC (direct current) value that 
produces the same heating (or work) 
in a purely resistive load. Therefore, 
a true RMS circuit makes accurate 
measurements even if the waveform 
is non-sinusoidal (or non-linear). 

So on sine waves, all three measure¬ 
ment techniques give the same read¬ 
ing. On non-sinusoidal waveforms, 
the readings of line voltages and 
currents can vary dramatically, as 
shown in Figure 1. 

For non-linear load currents, meas¬ 
urement with the average RMS me¬ 
ter can give a reading of one-half 
the actual value, or the true value is 
twice the average RMS meter 
reading. 

Harmonics and Non-Linear 
Loads 

Harmonics, as related to our subject, 
are multiples of the fundamental line 
frequency (60 Hz in the U.S.). The 
second harmonic is two times 60 Hz 
or 120 Hz. The third harmonic is 
three times 60 Hz or 180 Hz. Any 
non-sinusoidal waveform can be rep¬ 
resented by an infinite series of sine 
waves at integers of the fundamen¬ 
tal. With our non-linear load current, 
the waveshape of the current is usu¬ 
ally composed of the fundamental 
and up to the fiftieth harmonic with 
the third, fifth, seventh, and ninth be¬ 
ing the largest. The even harmonics 


are very small and usually 
insignificant. 

Earlier it was shown that a three- 
phase balanced linear load had zero 
current in the neutral. In a three- 
phase balanced non-linear load, the 
neutral current is not zero but con¬ 
sists of the third harmonic and odd 
multiples of the third. This is the 
third, ninth, fifteenth, twenty-first, 
and so on. What we find is that the 
odd multiples of the third do not can¬ 
cel at all in the neutral but are 
additive. 

In examining the typical input cur¬ 
rent of an SMPS, the current pulse 
waveform can be run through a pro¬ 
gram to do a harmonic analysis on 
it. The output of the analysis pro¬ 
vides a breakdown of the fundamen¬ 
tal and the individual harmonics up 
to the 25th or the 50th, depending 
on the program. The output can be 
listed as current in milliamps or 
amps or can be listed in percent of 
the fundamental. The fundamental is 
the single frequency component at 
the line frequency. A typical percent¬ 
age listing is shown in Figure 2. 

Since the third, ninth, and other odd 
multiples of the third harmonic add 
in the neutral wire, the neutral wire 
winds up carrying a current that is 
much greater than it had been de¬ 
signed to carry. 

Types of loads that are sources of 
harmonics are all types of AC-to-DC 
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Harmonic 

Percentage 

Fundamental 

100 

3rd 

70 to 90 

5th 

50 to 70 

7th 

20 to 40 

9th 

5 to 20 


Figure 2. Typical Percentage Listing 

converters such as motor speed con¬ 
trollers and rectifiers for DC loads, 
fluorescent lamps, motor-driven com¬ 
puter peripherals, and the fairly re¬ 
cent entry of the SMPS used in 
almost all computer and entertain¬ 
ment equipment. The conversion to 
SMPS has been accomplished with a 
reduction in size, weight, and cost, 
which has been the key to its univer¬ 
sal acceptance. 

Problems Caused by 
Harmonics 

This universal acceptance of SMPS 
and the attendant acceptance of per¬ 
sonal and other computers has led to 
the generation of a large problem 
list. When companies connect hun¬ 
dreds and thousands of PCs in a 
building, the triplen (odd multiples 
of the third) harmonic currents add 
to those of the other non-linear 
loads, creating unexpected electrical 
problems. Power line harmonics 
have been well documented to be 
the cause of: 

• Overheating of the neutral conduc¬ 
tor wires and connections, leading 
to failure of neutral conductors 
that could cause overvoltage dam¬ 
age to computers and electronic 
office equipment. This is ampli¬ 
fied by the wiring practice of re¬ 
ducing the wire size of the neutral 
conductor. 

• Intermittent electrical noise from 
connections that have been loos¬ 
ened by thermal cycling. This 


noise can be intense enough to 
corrupt digital circuit signals and 
cause malfunctions. 

• Transformer overheating, insula¬ 
tion damage and failure. 

• Distortion (peak voltage reduc¬ 
tion) of line voltage waveshapes 
severe enough to impair the ride- 
through capability of computers 
and related equipment. 

• Overheating of motors operating 
on a distorted voltage source. 

• Nuisance tripping of circuit 
breakers. 

• Burned wires in manufactured of¬ 
fice partitions. 

• Power factor correction capacitors 
overheated and damaged. 

(See Reference 2.) 



When companies connect 
hundreds and thousands 
of PCs in a building, the 
triplen harmonic currents 
add to those of the other 
non-linear loads, creating 
unexpected electrical 
problems. 

Detection of Problems 

The traditional measurement tech¬ 
nique for facility power distribution 
systems has been using average 
RMS meters. From the previous dis¬ 
cussion, the average RMS current 
meters provide a reading of about 
one-half of the true RMS high har¬ 
monic non-linear load. Measure¬ 
ments with average RMS meters 
made on building wiring and trans¬ 


former currents usually indicate cur¬ 
rents within ratings. 

Because of the harmonic problem, 
all measurements should be made 
with true RMS meters and all ancil¬ 
lary equipment (such as current 
transformers) should have frequency 
bandwidths to cover the probable 
harmonics. If peak current readings 
are also made, transformer deratings 
can be calculated using the formula 
provided by CBEMA in their 1988 
information letter. This measurement 
data can then be compared to the fa¬ 
cility ratings to detect problem areas. 

Equipment is available that meas¬ 
ures the true RMS currents and pro¬ 
vides a printout of the harmonic 
content of the currents. This meas¬ 
urement can be made on individual 
SMPS and other harmonic loads or 
can be made on the building distribu¬ 
tion wiring showing the total effects 
on wiring and transformers. 

Possible Solutions 

The possible solutions fall into four 
main categories. They are: 

• Passive filters 

• Filter traps 

• Active filters 

• Other facility changes 

Passive filters usually consist of a se¬ 
ries inductor and a third harmonic 
tuned filter and are located between 
the wall outlet and the offending 
non-linear device. They operate at 
line frequency so they are relatively 
bulky. They must be fairly well 
matched to the size of the load so 
that they do not cause an increase in 
RMS line current, even though har¬ 
monic currents are reduced. 

Filter traps are generally known as 
zero sequence filters or zig-zag trans¬ 
former filters , not the passive filter 
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just described. This filter is placed 
as close as possible to the offending 
load and at a point where three- 
phase wiring is available. Careful 
consideration must be given to the 
placement and sizing of the filter for 
a given power distribution system be¬ 
cause the filter attracts currents from 
other offending loads powered from 
that distribution net. This can be an 
effective method of correcting the 
problem with existing high harmonic 
loads. When distribution transform¬ 
ers have to be replaced or added, 
this type of filter can be built into 
the transformer. 

IBM Canada Ltd. has recently used 
the zig-zag transformer to dramati¬ 
cally reduce the harmonic current in 
the distribution panel of the office 
area of their Toronto manufacturing 
plant. The neutral current was re¬ 
duced 90 percent in their installation. 

Active filters add current to the exist¬ 
ing input current so that it gives a 
sine wave. They can work very well, 
but they are best for a high-power 
three-phase system, and they are 
very expensive, bulky, and complex. 

Some of the other facility changes 
mentioned in the CBEMA Informa¬ 
tion Letter are: 

• Derate the distribution 
transformers 

• Use individual neutral wires for 
each phase 

• Use dual neutral wires for shared 
neutral wiring 

• Use low impedance delta-wye dis¬ 
tribution transformers 

• Avoid the use of power factor cor¬ 
rection capacitors 


As is usually the case, the lowest- 
cost solution is probably a combina¬ 
tion of the solutions described. 

There should also be a periodic in¬ 
spection of the electrical system, es¬ 
pecially after additions of hardware 
or changes of system configurations. 
These inspections should include 
measurements of phase and neutral 
currents, temperatures of transform¬ 
ers, their connections and the con¬ 
nections in the total distribution 
system. Filter traps should also be 
looked at when system configura¬ 
tions change because the amount of 
current could possibly exceed its 
rating. 

System Power Supplies with 
Power Factor Correction 

An obvious question one could ask 
is, “Why not reduce the harmonics 
at the source?” The answer, of 
course, is that one can. There are cir¬ 
cuit approaches that force the input 
current to appear resistive and pro¬ 
portional to the line voltage and be 
in-phase. These approaches can be 
designed into new products for fu¬ 
ture sale and add some cost to the 
system. In Europe, an IEC 555-2 
standard is being changed to add har¬ 
monic limits. This standard applies 


to all household and other equip¬ 
ment (which includes the PC 
products). When this standard is 
approved and adopted, all PC 
products for Europe have to include 
power factor correction to meet the 
harmonic limits. 

Reference 1: Figure by A. McEachem. Con¬ 
tributed by BMI, Foster City, California, 

(415) 570-5355, University of Wisconsin-Mil- 
waukee Conference on “Effects of Non-Lin¬ 
ear Loads on the Power Distribution System,” 
April 5-6, 1989. 

Reference 2: Computer Business Equipment 
Manufacturers Association (CBEMA) Infor¬ 
mation Letter, 1988, and “DP Experience 
with Switching Supplies” by John M. 

Roberts, IBM. University of Wisconsin-Mil- 
waukee Conference on “Effects of Non-Lin¬ 
ear Loads On The Power Distribution 
System,” April 5-6, 1989. 
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Database 
Manager: 
Highlights and 
Direction 

Philip J. Sullivan 
IBM Corporation 
Austin , Texas 

Database Manager is IBM’s rela¬ 
tional database management sys¬ 
tem for Operating System/2® 
(OS/2). It offers a robust applica¬ 
tion development and run-time 
platform for a variety of OS/2 and 
DOS database applications. This 
article describes the capabilities 
and scope of Database Manager, 
and IBM’s intentions for future 
versions of the product. 

IBM OS/2 Extended Edition Version 
1.3 includes a Systems Application 
Architecture™ (SAA™) relational 
database management system, 
named Database Manager, that sup¬ 
ports the SAA Structured Query Lan¬ 
guage (SQL™). Database Manager 
can operate as a multiple-user client- 
server distributed relational database 
management system attached to a lo¬ 
cal area network (LAN) or as a 
stand-alone single-user relational 
database. 

Database Manager has benefited 
from IBM Research-developed data¬ 
base technologies and architectures, 
including the relational model of 
data and SQL. These IBM technolo¬ 
gies and architectures, coupled with 
the new technologies and architec¬ 
tures developed expressly for Data¬ 


base Manager, have positioned this 
product to be an industrial-strength 
relational database. It provides high 
performance, concurrent data access, 
robust data integrity and protection 
facilities, and consistency with the 
family of IBM SAA relational data¬ 
base management systems. 

Relational Model of Data 

Database Manager is predicated on 
the relational model of data. The re¬ 
lational model of data was invented 
by E. F. Codd at the IBM San Jose 
Research Center in the late 1970s. 
Today, the relational model has been 
widely accepted as an industry stand¬ 
ard by the marketplace. The rela¬ 
tional model has been designed to 
be easy to understand and use. Infor¬ 
mation is presented to the user in an 
easy to recognize and easy to use ta¬ 
ble format. A table is a logical data 
structure consisting of rows 
(records) and columns (fields). The 
user defines and accesses data in 
terms of tables and performs opera¬ 
tions on these tables. 

The main advantage of the relational 
database model is the clear separa¬ 
tion between the user perception of 
data, that is, tables consisting of col¬ 
umns and rows, and the internal im¬ 
plementation of data, which is 
hidden from the user. The simple ta¬ 
ble format, along with SQL and 
high-level application development 
tools, means that the application de¬ 
veloper and the database administra¬ 
tor do not have to understand 
complex physical data structures and 
access methods, which are charac¬ 
teristics of hierarchical file manage¬ 


ment systems. The benefits are ease 
of use and productivity. 

Structured Query Language 

SQL is the common interface to 
Database Manager and all IBM 
SAA relational database manage¬ 
ment systems. SQL, originally devel¬ 
oped at the IBM San Jose Research 
Center, has also become a standard 
in the industry. SQL is a high-level 
data definition and data manipula¬ 
tion language, used for defining, ac¬ 
cessing, and changing data in tables. 

SQL is considered simple to learn, 
yet powerful in expressing sophisti¬ 
cated queries. A single statement in 
SQL can perform the same function 
as many lines of application code de¬ 
veloped with a conventional pro¬ 
gramming language, such as C, 
COBOL, FORTRAN, or Pascal. 

All data accesses to Database Man¬ 
ager are performed with SQL state¬ 
ments through the SQL common 
interface. SQL supports arithmetic 
operations on retrieved values. The 
query functions support selective re¬ 
trieval from single or multiple data 
tables and dynamic sorting of the set 
of resulting rows. Built-in functions 
include summation, grouping, order¬ 
ing, and basic statistics (for exam¬ 
ple, calculating an average of the 
values in a column). 

SQL statements can be entered inter¬ 
actively (through Query Manager, 
described later in the article), embed¬ 
ded in a precompiled application pro¬ 
gram written in a high-level 
programming language, or embed¬ 
ded in an application program writ- 
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ten with IBM Procedures Language 
2/REXX. Database Manager pro¬ 
vides language precompilers to pre¬ 
pare embedded SQL statements for 
subsequent application program com¬ 
pilation and execution by Database 
Manager. Precompiler support is 
provided for IBM C/2, IBM 
COBOL/2™, IBM FORTRAN/2™, 
and IBM Pascal/2™. 

Database Manager supports both 
Static SQL and Dynamic SQL state¬ 
ments embedded in an application 
program. The difference between 
Static SQL and Dynamic SQL is the 
instance when compilation of the 
statements occurs at the database. 

For Static SQL statements, the com¬ 
pilation occurs during precompiling 
or binding of the application to Data¬ 
base Manager. The compilation is 
done only once, no matter how 
many times the statements are exe¬ 
cuted during the course of running 
the application. Dynamic SQL state¬ 
ments are compiled each time the 
statements are executed during the 
course of running the application. 
Static SQL is a more efficient proc¬ 
ess and will, in most instances, pro¬ 
vide better performance than 
Dynamic SQL. However, if the ap¬ 
plication must issue arbitrary SQL 
queries, Dynamic SQL is required. 

Client-Server Distributed 
Database Architecture 

Database Manager has been de¬ 
signed to be a multiple-user client- 
server distributed database 
management system for IBM OS/2 
local area network environments. 

The architecture provides for separa¬ 



tion of the application program from 
the database itself. 

Database Manager remote-unit-of- 
work functions provide OS/2 and 
DOS client applications with the ca¬ 
pability to transparently access data 
(read and update) in a single remote 
OS/2 database server, per unit-of- 
work. A client application can also 
serially access multiple databases. 

Database Manager client-server dis¬ 
tributed database architecture pro¬ 
vides a cost-effective solution to a 
wide-range of applications, such as 
decision-support and personal pro¬ 
ductivity applications, which require 
multiple users to have fast, concur¬ 


rent, and easy access to consistent 
data. 

Performance 

Database Manager has demonstrated 
excellent performance. In October 
1990, the National Software Testing 
Laboratory (NSTL) published results 
of benchmark tests of Database Man¬ 
ager. The purpose of the tests was to 
compare the performance of Data¬ 
base Manager with three competitive 
offerings, each one a participant in 
the OS/2 client-server database mar¬ 
ketplace. The test results showed Da¬ 
tabase Manager to have comparable 
or superior performance capability 
to the competitive offerings in three 
of four client-server application sce- 
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narios. In the fourth scenario, Data¬ 
base Manager, while not faster than 
the competition, was competitive. 

IBM database technologies have 
been applied to enhance perform¬ 
ance; for example, query optimiza¬ 
tion techniques, join algorithms, and 
indexing and locking techniques. 
Record Level Locking allows maxi¬ 
mum concurrent access to data and 
is especially important to database 
transaction processing performance. 
Granular levels of data isolation are 
provided to enhance performance. 
These include Repeatable Read , 
Cursor Stability , and Uncommitted 
Read. 

Database Application Remote Inter¬ 
face may be used to enhance per¬ 
formance. It allows a developer to 
write an application program where 
the application processing can be 
split between the database client and 
the database server on a local area 
network. When the application is 
run, some of the application process¬ 
ing load can be transferred from the 
client to the server, resulting in a re¬ 
duction of data traffic on the LAN 
and a significant improvement in 
database application performance. 

Robust Data Integrity and 
Protection 

Database Manager has extensive 
data integrity and protection features 
to preserve the integrity of data, 
thereby ensuring users that informa¬ 
tion being accessed is consistent. 

Transaction Management is a fea¬ 
ture that allows multiple applications 
to run concurrently against common 
tables in Database Manager. 

Through the use of transaction man¬ 
agement, Database Manager pro¬ 
vides a high level of data control 
and protection against serialization 
problems and database transaction 


failures in a multiple-tasking, multi¬ 
ple-user database environment. If an 
application accesses Database Man¬ 
ager and terminates normally, a 
COMMIT statement is issued, which 
allows the database updates to be¬ 
come permanent. If an application is 
interrupted in the midst of a transac¬ 
tion, the system can perform a 
ROLLBACK on all uncompleted 
work after an application failure, or 
on the next system restart after a sys¬ 
tem failure. These functions help en¬ 
sure the integrity and consistency of 
the database information. 



Database Manager has 
extensive data integrity 
and protection features. 


Database Manager provides transac¬ 
tion management through the use of 
locks, multiple levels of data isola¬ 
tion, and a Recovery Log. The lock 
function and the specified level of 
data isolation are used to prevent an¬ 
other application from updating a 
data record while a transaction is 
pending against that record. All 
changes to data tables and indexes 
have entries written to the Recovery 
Log that provide sufficient informa¬ 
tion to allow Database Manager to 
back out of an update before any 
changes are written to the data. 

Through the use of the Recovery 
Log , updated during normal data¬ 
base processing using a write-ahead 
logging scheme, Database Manager 
can return the database to a consis¬ 
tent state after system failures, such 
as a power failure, a user-initiated 
system reset, or a software failure 


(except in some instances where logi¬ 
cal media failure has occurred). In 
the event of such a failure. Database 
Manager can undo and redo the nec¬ 
essary database operations to return 
the database to a consistent state by 
retrieving and reconstructing commit¬ 
ted data and rolling back uncommit¬ 
ted data using the Recovery Log. 

Database Manager is also capable of 
restoring a backup copy of a data¬ 
base, where data on the media, disk 
or diskette is destroyed by physical 
or logical damage. Physical media 
failure can occur due to a bad sector 
on the disk or diskette. Logical me¬ 
dia failure can occur when data is 
over-written by another program and 
becomes unrecognizable to Database 
Manager. Logical media failure can 
also occur if a system fails during a 
data update, such that some sectors 
are left unchanged while some are 
updated. Database Manager attempts 
to recover from logical media fail¬ 
ures using the Recovery Log. If this 
attempt fails, the backup copy of the 
database must be restored. 

Referential Integrity is another im¬ 
portant feature used to provide ro¬ 
bust data integrity and protection. It 
ensures the consistency of data val¬ 
ues among related columns of differ¬ 
ent tables. For example, a user may 
define an EMPLOYEE table that 
contains employee and department 
numbers and a DEPARTMENT ta¬ 
ble that contains department num¬ 
bers. In addition, the user may want 
to ensure that for every department 
number in the EMPLOYEE table 
there must be an equal and unique 
department number in the DEPART¬ 
MENT table. Such a constraint de¬ 
fined on the EMPLOYEE table is 
called a referential constraint. The 
department number in the DEPART¬ 
MENT table is called a primary key, 
and the department number in the 
EMPLOYEE table is called the for- 
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eign key in this constraint. Enforce¬ 
ment of this constraint provides ref¬ 
erential integrity. The Database 
Manager records and enforces this 
data relationship, and enforcement 
by application logic is not necessary. 

In addition to ensuring the consis¬ 
tency of data, Referential Integrity 
can also improve application devel¬ 
opment productivity by allowing this 
function to be moved out of each ap¬ 
plication program and into the Data¬ 
base Manager. 

Data Security 

In any database environment, there 
is a need to protect information from 
unauthorized access. Database Man¬ 
ager provides for protection from 
unauthorized access of data by a 
granular grant/revoke privileges 
scheme. 

SQL Grant/Revoke Security prevents 
unauthorized access by coordinating 
security functions through an OS/2 
Extended Edition component called 
User Profile Management and 
through SQL GRANT/REVOKE 
Authorization statements. User Pro¬ 
file Management establishes access 
levels used by Database Manager. 

In order to access and use objects in 
the Database Manager, the user must 
be identified to User Profile Manage¬ 
ment and be validated by a pass¬ 
word on the first use of the Database 
Manager. The user is then associated 
with a valid user ID. Access to a spe¬ 
cific database and the objects within 
it (for example, tables, views, and 
access plans) is controlled by SQL 
GRANT/REVOKE statements. A 
creator or other specifically author¬ 
ized user of a database object (such 
as a systems administrator or data¬ 
base administrator) may protect the 
object by only granting access rights 
to specific users and/or groups. An¬ 


other user must be specifically 
authorized to access and update a da¬ 
tabase object. These rights can also 
be revoked as required. A creator 
also has the option to allow public 
access to all database objects. 

IBM SAA Relational 
Database Consistency 

Database Manager is a member of 
the family of IBM SAA relational 
database management systems: IBM 
Database 2 (DB2) and IBM Struc¬ 
tured Query Language/Data System 
(SQL/DS™), which run on IBM Sys¬ 
tem/390™ and IBM System/370™ 
mainframe and mid-range systems, 
and IBM OS/400™ database man¬ 
ager, which runs on the IBM Appli¬ 
cation System/400™. 

Syntax and Semantics of the Data¬ 
base Manager SQL interface func¬ 
tions are designed for consistency 
with the family of IBM SAA rela¬ 
tional databases. For example, the 
consistent handling of host variables, 
precompile, bind, and query optimi¬ 
zation simplifies the application 
developer’s work in writing hetero¬ 
geneous cross-system applications 
for an enterprise-wide distributed da¬ 
tabase environment. 

Import Data from DB2 and 
SQL/DS Databases 

Database Manager provides a facil¬ 
ity, named SQLQMF, which allows 
users to import table data stored in 
DB2 or SQL/DS into a Database 
Manager database. The SQLQMF fa¬ 
cility takes host data exported by the 
IBM Query Management Facility 
(QMF™), stored in QMF format, 
down loads the data, and converts it 
into a file that can be imported into 
a Database Manager table. 


Database Manager 
Components 

Database Manager consists of three 
major components: Database Serv¬ 
ices, Remote Data Services, and 
Query Manager. 

Database Services: Accesses to 
Database Manager are performed by 
Database Services through the SQL 
common programming interface 
(CPI) and utility application pro¬ 
gramming interfaces (APIs). Data¬ 
base Services manages the data 
stored in the database, generates ac¬ 
cess plans to the data, and includes 
transaction-management, data integ¬ 
rity and protection, multiple-user 
concurrency, and security functions. 

Database Services also provides a 
number of utility functions that 
assist the user in maintaining and 
manipulating the contents of a data¬ 
base. These utilities include func¬ 
tions to import and export data from 
a DOS or OS/2 file, save and restore 
individual data tables, perform data¬ 
base backup and restore functions, 
and optimize system performance. 

Remote Data Services: Remote 
Data Services provides database con¬ 
nection services to allow Database 
Manager to function as a client-serv¬ 
er distributed database management 
system on a LAN. This capability al¬ 
lows multiple OS/2 and DOS per¬ 
sonal computer client applications to 
transparently access a remote OS/2 
distributed database server attached 
to a LAN, or stand-alone OS/2 per¬ 
sonal computer clients not attached 
to a LAN, to access a remote OS/2 
distributed database server. 

Remote Data Services supports the 
following LAN environments: IBM 
Token-Ring, IBM PC Network 
LAN, or ETHERAND™ and IEEE 
802.2. OS/2 database clients and 
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servers utilize the APPC communica¬ 
tion protocol, provided by Communi¬ 
cations Manager, or the SQL 
LAN-Only Option (SQLLOO) to 
connect in a LAN environment. 

APPC is also used to connect re¬ 
mote OS/2 database clients to re¬ 
mote OS/2 database servers. DOS 
database clients attached to a LAN 
utilize the NetBIOS communication 
protocol to connect to a remote 
OS/2 database server. 

Query Manager: Query Manager 
provides database tools and func¬ 
tions that allow users to access, 
manipulate, and administer data in 
Database Manager. 

Query Manager provides an easy to 
use prompted user interface, which 
is based on the SAA Common User 
Access (CUA) guidelines and takes 
advantage of the OS/2 Presentation 
Manager™ windowing and graphic 
services. The prompted interface 
hides SQL from the application user, 
so the user does not have to learn 
SQL syntax. However, once a 
prompted query has been created, its 
SQL syntax can be viewed option¬ 
ally. This allows users to learn SQL 
syntax so they can enter SQL state¬ 
ments in a non-prompted mode, if 
desired. 

Query and Report Writing Tools pro¬ 
vide functions to create a database 
query (inquiry), initiate the data ac¬ 
cess request, and display the results 
of the query via the report feature. 
The user may save the query and 
report objects and save or print the 
accessed information. A Business 
Graphics Interface allows the user to 
optionally install and use a third 
party business graphics program writ¬ 
ten to this interface. This permits 
graphic presentation (pie, line, bar, 
tower graphs, and so forth) of report 
data that was accessed by the query 
and report features. 


Custom Application Tools provide 
functions that allow a user to create 
custom database applications. Panels 
may be used to create custom data 
entry and edit formats. Procedures 
may be used to create Query Man¬ 
ager commands or procedure lan¬ 
guage statements to execute 
previously defined query and form 
(report) objects, or to combine and 
automate several panel operations. 
Menus may be used to create a cus¬ 
tomized list of application selec¬ 
tions. Items listed on the menu may 
be selected to initiate and automat¬ 
ically run queries, generate reports, 
run and call procedures, panels, and 
other menus. 



Query Manager provides 
an easy to use prompted 
user interface 


Database Administration Tools pro¬ 
vide functions to administer and 
manage a database system; for exam¬ 
ple, creating, altering, and dropping 
tables, views, indexes; entering and 
editing data; defining referential con¬ 
straints; importing and exporting 
data; reorganizing tables; monitoring 
database activities. One of the Data¬ 
base Manager features that is sup¬ 
ported through Query Manager is 
Operational Status , which provides 
a snapshot of information about cur¬ 
rent database activity. This feature 
provides information about where 
the databases are located, alias 
names, the time and date a database 
was last backed up, and how many 
applications are currently connected 
to a specific database. 

A command line is also provided for 
users to issue Query Manager com¬ 


mands directly. These commands in¬ 
clude functions such as print, get, im¬ 
port, and display. These commands 
may be used to execute Query Man¬ 
ager objects, such as Procedures, di¬ 
rectly from the command line. 

Future Versions and 
Releases of Database 
Manager 

Future versions and releases of Data¬ 
base Manager will focus on provid¬ 
ing industrial-strength distributed 
relational database solutions for 
stand-alone LAN environments and, 
in concert with other IBM SAA rela¬ 
tional database products, enterprise¬ 
wide distributed relational database 
solutions for interconnected LANs, 
and host systems. Emphasis will be 
placed on data integrity and protec¬ 
tion, concurrency, connectivity and 
interoperability, database administra¬ 
tion, usability, security, perform¬ 
ance, capacity, and availability. 

1991 Direction 

OS/2 Database Manager Access to 
IBM SAA Host Databases: As 
IBM begins the roll-out of heteroge¬ 
neous SAA distributed relational da¬ 
tabase functions. Database Manager 
will initially provide functions to 
support heterogeneous remote-unit- 
of-work (RUOW) database 
applications. 

Support for RUOW and the IBM 
Distributed Relational Database Ar¬ 
chitecture (DRDA) will allow Data¬ 
base Manager client applications 
(OS/2, Windows 3.0, and DOS) to 
transparently access (read and up¬ 
date) a single remote IBM SAA host 
distributed relational database per 
unit-of-work. A Database Manager 
client application will also be able to 
serially access multiple SAA host 
relational databases. 
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Distributed Database Application 
Gateways , as single-user and multi¬ 
ple-user offerings, will provide the 
transparent connection between per¬ 
sonal computer database clients and 
an IBM SAA host relational data¬ 
base server, such as DB2, SQL/DS, 
or the OS/400 database manager. 

Forward Recovery: Data protec¬ 
tion is essential to customers who 
have mission-critical database appli¬ 
cations, such as an online order en¬ 
try application. Database Manager 
capabilities will be enhanced 
through the addition of Forward 
Recovery functions. 

Forward Recovery, also known as 
“Archival Log,” will allow the user 
to recover lost online data due to 
media failure, such as a disk crash. 
During normal online database trans¬ 
actions, information necessary to 
maintain data integrity and consis¬ 
tency is preserved on log journals. 
Journals are normally kept on 
separate media from the database. 
Should media failure occur, a 
backup off-line copy of the database 
may be loaded on the system and 
restored as the online database. For¬ 
ward Recovery provides the means 
to apply log journal information 
against the restored database. Log 
journals contain changes made to the 
online database since the last backup 
(off-line copy) of the online data¬ 
base was made. After forward recov¬ 
ery has been completed, the state of 
the online database is as it was prior 
to the media failure and subsequent 
loss of data. 

The addition of Forward Recovery is 
consistent with IBM’s direction to 
continue to focus on providing lead¬ 
ership in database functions. For¬ 
ward Recovery enables Database 
Manager to be used for a variety of 
mission-critical applications, such as 


online transaction processing 
(OLTP). 

Microsoft® Windows™ 3.0 
Support: Database Manager DOS 
Database Requester functions will 
be enhanced to provide support for 
applications developed for the Mi¬ 
crosoft Windows 3.0 environment. 
With this capability, Windows 3.0 
client applications written to the 
Database Manager SQL CPI will be 
able to transparently access a remote 
Database Manager server attached to 
a LAN. 

NetBIOS Support for OS/2 Clients: 

NetBIOS support for OS/2 clients 
will be provided as an optional LAN 
communication connectivity proto¬ 
col to an OS/2 database server. 
NetBIOS is a popular personal com¬ 
puter protocol for connecting per¬ 
sonal computers together. NetBIOS 
will require less random access mem¬ 
ory (RAM) than APPC, which will 
result in a reduction in the amount 
of memory required for client work¬ 
stations. This option will also sim¬ 
plify database installation and 
configuration. 

Database Tool Enhancements: 

Database Administration Tools will 
be provided as a separate installable 
option. The tools will include func¬ 
tions to configure Database Manager 
and a database, backup and restore a 
database, perform forward recovery, 
and configure remote client-server 
and gateway connections. The Data¬ 
base Administration Tools will have 
graphical user interfaces that provide 
an easy-to-use prompted interface 
based on SAA CUA guidelines and 
take advantage of the OS/2 Presenta¬ 
tion Manager windowing and 
graphic services. 

Database Manager Command Inter¬ 
face will allow users to create and 
run SQL statements, database envi¬ 


ronment commands, and database 
utilities from the OS/2 command 
line interface and from OS/2 com¬ 
mand files. Included with the Data¬ 
base Manager Command Interface is 
a facility (Re-Org Check) to inform 
the database administrator that it is 
beneficial to reorganize a table in 
the database, so that performance 
may be improved. 

Support for Non-IBM Personal 
Computer Platforms: Database 
Manager will be enabled to run on 
selected IBM-compatible personal 
computer hardware systems. Support 
for non-IBM systems will extend the 
versatility of Database Manager and 
provide additional flexibility in 
selecting hardware platforms: IBM 
PS/2 solutions, non-IBM hardware 
solutions, or mixed IBM and non- 
IBM hardware solutions. 

SAA Relational Database 
Compatibility Enhancements: 

SAA enhancements will improve 
Database Manager compatibility 
with the IBM family of SAA rela¬ 
tional database products. 

SQL Date and Time Arithmetic and 
Scalar functions will allow applica¬ 
tions to add and subtract the follow¬ 
ing data types: TIME, DATE, and 
TIMESTAMP. An example of the 
use and value of SQL 
DATE/TIME/TIMESTAMP is an ap¬ 
plication designed to track and moni¬ 
tor the elapsed time of a commercial 
airline flight from the originating 
city and gate to the destination city 
and gate. 

SQL State will provide applications 
with diagnostic information that is 
common across the family of IBM 
SAA relational database manage¬ 
ment systems. This capability makes 
possible the development of error 
handling routines that are consistent 
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with and portable across the SAA 
database family. 

User Defined Collating Sequence 
will allow the database user to spec¬ 
ify methods that will be used to sort 
and compare character data. This op¬ 
tion may be used to ensure collating 
results that correspond to IBM host 
systems, such as System/370. 

Translate: Translate will allow the 
user to transform character data in 
various ways; in particular, it allows 
characters to be converted to their 
uppercase or lowercase equivalents. 
This capability makes possible case- 
insensitive searches. 

Database Manager “Front-Ends” 
(Database Applications and Tools): 

IBM will continue to provide Data¬ 
base Manager technical support to 
complementary independent applica¬ 
tion developers and to business part¬ 
ners. This support will be provided 
through developer assistance pro¬ 
grams, whose purpose is to provide 
assistance in the design and develop¬ 
ment of a variety of OS/2 Presenta¬ 
tion Manager, Windows 3.0, and 
DOS database applications and 
tools, such as general purpose query 
and report writers and customizing 
tools that work with Database 
Manager. 

Make Available Database 
Manager Code to Selected 
Software Developers: IBM’s direc¬ 
tion is to make components of Data¬ 
base Manager code available to 
complementary software developers 
who meet IBM’s selection criteria. 
Selected software developers may in¬ 
tegrate, package, and market Data¬ 
base Manager code with application 
programs they develop. General-pur¬ 
pose database query and report writ¬ 
ing programs, and industry-specific 
custom application programs are ex¬ 


amples of the types of programs that 
may use Database Manager code. 

Database Manager code can provide 
the software developer with indus¬ 
trial-strength relational database 
management services, distributed 
database application connection 
services to OS/2 database servers 
attached to a LAN, and distributed 
database application connection 
services to IBM SAA host relational 
databases. 

Future Direction 

Distributed Database 
Enhancements: Over time. Data¬ 
base Manager will be enhanced to 
provide additional distributed data¬ 
base functions. Support will be pro¬ 
vided for increasingly more complex 
data access, such as distributed unit- 
of-work, distributed (SQL) state¬ 
ments, and distributed tables. 

Compatible 32-Bit OS/2 and 
AIX® Database Managers: IBM’s 
direction is to provide compatible 32- 
bit client-server SAA and AIX Data¬ 
base Managers that fully exploit the 
32-bit OS/2 and AIX platforms. The 
32-bit OS/2 Database Manager will 
be provided for Intel®-based PS/2 
computers and IBM-compatible per¬ 
sonal computers. The 32-bit AIX Da¬ 
tabase Manager will be provided for 
IBM RISC System/6000™ platforms. 

The OS/2 Database Manager and the 
AIX Database Manager will be opti¬ 
mized for LAN performance and in¬ 
teroperability, conform to industry 
and defacto standards, and provide 
enhanced capabilities. 

Parallel Database Processing: 

IBM’s direction is to enhance 
Database Manager to provide 32-bit 
parallel database processing. Parallel¬ 
ism will support multiple system 
processor nodes, such as multiple 


PS/2 computers, or multiple RISC 
System/6000 computers, that are 
linked together to present a 
single-system image. 

Database Manager parallel functions 
will provide customers with high 
throughput rates, fast response 
times, access to very large (giga¬ 
bytes) amounts of information, and 
fault-tolerant functions. Database 
parallelism will be especially benefi¬ 
cial to online transaction processing 
applications where fast response 
time and high availability are essen¬ 
tial. Parallelism will also offer sig¬ 
nificant benefits to advanced 
complex-data applications, such as 
image and multimedia, where access 
to large amounts of data are applica¬ 
tion characteristics. 


ABOUT THE AUTHOR 

Phil Sullivan is a senior product 
planner in the IBM Personal 
Systems Programming Center in 
Austin, Texas. He joined IBM in 
1966 as a marketing representative 
and has held various management 
and staff positions in marketing and 
product planning. For the past 10 
years, Phil has been involved in the 
product planning of personal 
computer software products. He is 
currently responsible for IBM 
personal systems database product 
and market strategy. Phil holds a 
B.S. in economics from Mount St. 
Mary's College. 


Much of this information concerns future prod¬ 
ucts, or future releases of products currently 
commercially available. The discussion on 
Windows 3.0 is based on information that Mi¬ 
crosoft Corporation has made publicly avail¬ 
able and is subject to change. The description 
of IBM’s future products, performance, func¬ 
tions, and availability are based upon IBM’s 
current intent and are subject to change. 


Personal Systems/Issue 4, 1991 



13 


OS/2 

Communications 

Manager 

Rich Harrison 
IBM Corporation 
Austin , Texas 

This is an updated version of a 
Communications Manager document 
distributed by IBM April 16, 1991. 

Communications Manager is IBM’s 
strategic workstation-based com¬ 
munications offering. It provides 
many concurrent networking capa¬ 
bilities. This article describes the 
wide range of services offered by 
Communications Manager, the 
value of its features to the user 
and developer, and IBM’s plans 
for enhancements to be included 
in the OS/2 2.0-based version. 


Communications Manager (CM) is 
one of the major components of Op¬ 
erating System/2 Extended Edition 
(OS/2 EE). CM provides a rich set 
of terminal emulation, LAN gate¬ 
way, host connectivity, and worksta¬ 
tion communication capabilities. CM 
exploits vital functions of OS/2 such 
as preemptive multitasking and I/O 
overlapping and is intended to facili¬ 
tate the development of applications 
that require communications be¬ 
tween two or more systems or work¬ 
stations. By including most of the 
required communications functions 
within one component, application 
developers are relieved of under¬ 
standing the low-level detail of com¬ 
munication tasks and may rely on 
CM to accomplish them quickly and 
efficiently. Additional services in the 
form of emulation functions are 
available to the end user, and facili¬ 
ties are included for use by the Net¬ 


work administrator who may be deal¬ 
ing with the management and con¬ 
trol of large numbers of end users. 

OS/2 EE is part of the IBM Systems 
Application Architecture (SAA) fam¬ 
ily, which itself provides the plat¬ 
form for the development of 
portable applications for, and the in¬ 
terconnection of, cooperative SAA 
systems. As we move further into 
the 90s, customers will increasingly 
take advantage of the opportunities 
offered by “distributed processing”; 
that is, the ability to undertake proc¬ 
essing on whichever system is most 
appropriate, with all systems being 
interconnected across a network. 

This environment will make even 
heavier demands on communications 
and increase the need for a versatile 
and robust communications subsys¬ 
tem such as CM. 
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What distinguishes CM from other 
communications offerings is its de¬ 
sign and integration with the OS/2 
environment and SAA. CM provides 
multiple concurrent connectivities, 
supports multiple concurrent proto¬ 
cols, allows concurrent emulations 
of different terminal types, and al¬ 
lows simultaneous file transfers. It 
also supports several APIs designed 
for the traditional and the contempo¬ 
rary program development environ¬ 
ments, and has requisite interfaces 
for network management. All these 
aspects will be elaborated upon in 
the remainder of this article. 

In short, CM provides the opportu¬ 
nity for productivity improvements 
for the program developer, the end 
user, and the network administrator. 
In particular, when the user is 
integrated into the network and has 
access to the organizational informa¬ 
tion processing assets, CM is 
extremely attractive. 

IBM plans to make CM more open 
by allowing it to run on both IBM 
and other manufacturers’ Intel-based 
hardware using the vendor’s OS/2 
Standard Edition (SE). 

Systems Application 
Architecture (SAA) 

Communications Manager, in con¬ 
junction with OS/2 SE, participates 
in SAA, which provides the frame¬ 
work for consistency in the user 
interfaces, the programming inter¬ 
faces, and the underlying communi¬ 
cations support. The workstation is 
the window to the customer’s enter¬ 
prise-wide information system. It is 
vital that the user see a consistent 
and familiar means of access to and 
presentation of information regard¬ 
less of the location of the system. 
Applications written to SAA specifi¬ 
cations ensure that this occurs. This 
makes it easier for users to learn 


new applications and to move from 
one application to another. 

SAA can take these concepts one 
step further. It provides the capabil¬ 
ity for programs to be written across 
the computing environments of Sys¬ 
tem/370, AS/400, and the Personal 
System/2®. The implication is not 
only that programs can work coop¬ 
eratively across these hardware 
platforms, but also that programs 
written for one may be actually trans¬ 
ferred to another. This is important 
because it allows workloads to be 
shifted as they grow or evolve over 
time. 

Programming interfaces are covered 
by SAA, too. The strategic interface 
for distributed processing is Com¬ 
mon Programming Interface - Com¬ 
munications (CPI-C). By writing to 
CPI-C, developers may confidently 
know that their applications will con¬ 
tinue to be applicable within the 
SAA family into the future. CPI-C is 
currently available through a com¬ 
panion product - Networking Serv¬ 
ices/2. IBM’s plan is to integrate 
this support into CM in the future. 

Also available are interfaces to Pres¬ 
entation Manager. These interfaces 
enable developers to write high-per¬ 
forming, full-function applications 
that can be tailored to a specific user 
or environment. Calls may be used 
to control the program groups that a 
user sees and can access. This al¬ 
lows personalization of the system 
to a specific user or group of users. 
Presentation Manager has utilities 
for the printing/plotting, display, and 
interchange of picture files. 

CM contains the Common Commu¬ 
nications support that allows pro¬ 
gram interchanges among various 
systems. This takes place transpar¬ 
ently to the end user and it is impor¬ 
tant because it ensures that such 


interchanges take place efficiently 
and reliably. It is also very impor¬ 
tant to developers because it relieves 
them from having to write the rou¬ 
tines that accomplish the communi¬ 
cations functions. In complex 
environments with multiple transfers 
of data taking place simultaneously, 
all the power of CM and the preemp¬ 
tive multitasking capability of OS/2 
are required to ensure that every¬ 
thing works smoothly. By using the 
facilities of CM, this process is 
taken care of in whichever communi¬ 
cations environment the application 
is run. The details of this process are 
described the sections that follow. 

Connectivity Support 

Various methods have been used 
over the years to allow systems, con¬ 
trollers, terminals, and workstations 
to talk to each other. IBM’s Systems 
Network Architecture (SNA) is a ro¬ 
bust architecture that has become ac¬ 
knowledged as an industry standard. 
SNA supports both hierarchical and 
peer type networks. SNA networks 
are very prevalent today and are typi¬ 
cally based on links using the Syn¬ 
chronous Data Link Control (SDLC) 
protocols between the host and other 
systems or controllers, and Distrib¬ 
uted Function Terminal (DFT) proto¬ 
cols for terminals coax-attached to 
their controller. CM supports both 
these environments, the latter in the 
context of PCs being substituted for 
the fixed-function terminals (3270). 

In recent years, there has been a 
strong trend toward the use of local 
area networks (LANs) to tie together 
the proliferating number of PCs in 
the workplace so they could share 
resources and access each other’s 
data. Many different approaches 
were introduced before the leading 
industry LANs were identified. IBM 
initially introduced the PC Network 
LAN before adopting the Token- 
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Ring LAN as its strategic offering. 
Both the Ethernet™ and Token-Ring 
LAN have achieved very broad 
acceptance by the industry. Ethernet 
comes in several forms, the most 
popular of which are known as DIX 
Version 2.0 and IEEE 802.3. In 
order to allow its applications to run 
in the LAN environment, CM sup¬ 
ports all the LANs mentioned in this 
paragraph. 

Other ways for systems to communi¬ 
cate over a wide area network 
(WAN) include X.25 and ASYNC. 
The X.25 Packet Switched Data Net¬ 
works (PSDNs) are available world¬ 
wide, generally through the official 
telephone and telegraph providers in 
Europe and elsewhere, and through 
private utilities and corporations in 
the U.S. They are an alternative and 
often cheaper way of transmitting 
data over a distance and use their 
own, standardized, link level proto¬ 
cols to interface with subscribers. 

CM supports the use of X.25 serv¬ 
ices both through the PSDNs and 
also using direct connection. 

ASYNC is a simple, inexpensive 
way to access many of the financial, 
news, and informational bulletin 
board services that are springing up 
everywhere. Many systems, includ¬ 
ing several from IBM, use ASYNC 
either as a primary or secondary 
approach for communications. All 
PS/2s are equipped with ASYNC 
capability as part of the base product 
and CM provides essential ASYNC 
support. IBM plans to extend sup¬ 
port to include the DMA ASYNC 
capability provided in the PS/2 
Models 90 and 95. 

From the preceding it should be evi¬ 
dent that CM has a broad range of 
networking capabilities that allow 
communications across a range of 
IBM systems, as well as many het¬ 
erogeneous non-IBM environments. 


The applications can be used simulta¬ 
neously with those developed by oth¬ 
ers, without having to take any 
specific action other than designing 
and developing the application with 
CM. This function, along with the 
rich networking capabilities de¬ 
scribed in the preceding section, 
represent a robust workstation com¬ 
munications offering. 

Terminal Emulation 

Three distinct families of terminals 
may be emulated using the functions 
of CM on a PS/2 workstation. They 
are: 3270 to a System/370 host, 

5250 to an AS/400 host, and ASCII 
to a variety of IBM, and selected 
IBM-compatible and non-IBM, hosts. 



Multiple 3270 sessions 
can be active at any one 
time. 


3270 Emulation: Interactive ac¬ 
cess to a System/370 host is sup¬ 
ported through 3270 terminal 
emulation using the IBM LU2.0 pro¬ 
tocol and can be defined to emulate 
the more commonly installed termi¬ 
nals. Connection may be via any of 
the previously described links, with 
the exception of ASYNC. In the 
case of LAN connections, some 
form of gateway is required (this is 
described in the section “LAN 
Gateways”). 

All 3270 base data stream functions 
are supported together with extended 
attributes and extended data stream 
functions (with seven colors and ex¬ 
tended highlighting, plus online 
choice of fonts for the EGA, VGA, 
XGA, and IBM 8514/A displays). 


The 3270 terminal emulation sup¬ 
ports multiple interactive screens 
and keyboard remapping, as well as 
Emulator High Level Language API 
(EHLLAPI), which is described in 
more detail under the API section. 

This means that 3270 terminals may 
be replaced by PS/2s, and the 3270 
programs may be run with no loss of 
function. However, considerably 
more advantage can be taken of the 
power of the PS/2 compared to its 
fixed-function terminal counterpart. 

For example. Presentation Manager 
windowing provides the ability to 
save and restore panel characteristics 
and clipboard editing functions. Win¬ 
dowing allows multiple simultane¬ 
ous applications typical of OS/2, as 
well as applications in other win¬ 
dows that can be monitored at the 
same time that 3270 emulation is 
running. 

The editing functions allow data to 
be transferred among applications 
running in different panels. Simple 
text, text with attributes, and bit im¬ 
ages are supported for the mark, cut, 
copy, and undo operations, whereas 
simple text is supported for the paste 
operation. This means that informa¬ 
tion can be combined from different 
sources for purposes such as input to 
a report. 

Multiple 3270 sessions can be active 
at any one time. Each of these ses¬ 
sions can support terminal emula¬ 
tion, host-directed print, or file 
transfer, and they can use an API 
(EHLLAPI or Server-Requester Pro¬ 
gramming Interface [SRPI]) at any 
time regardless of the method of con¬ 
nection. Each active 3270 session 
runs in its own window, and select¬ 
ing between sessions is done with 
the mouse or keyboard. This means 
that a user may be servicing a pay¬ 
roll enquiry, transferring a file con- 
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taining a report, and printing the lat¬ 
est price list, all at the same time. 
This capability can enable substan¬ 
tial productivity gains. 

An active 3270 session can be used 
to move data between a workstation 
and a System/370 host (in either di¬ 
rection). This file transfer capability 
provides appropriate translations (if 
required) when data is exchanged 
with the host. File transfer to and 
from an MVS/TSO, VM/CMS, 

CICS, or VSE/SP host can be per¬ 
formed through any active 3270 ses¬ 
sion; the only prerequisite is that the 
IBM 3270 PC File Transfer program 
must be installed and made accessi¬ 
ble on the host computer. (Note: 

IBM plans to make long file names - 
up to 255 characters - already sup¬ 
ported in OS/2 SE, part of 3270 file 
transfer support in the future.) 

Multiple file transfers can be per¬ 
formed concurrently. Because 3270 
file transfer may be going on in the 
background while the user is free to 
continue with other work, this is a 
powerful and efficient method of 
shipping files, reports, and docu¬ 
ments around an organization. 

Communications Manager also con¬ 
tains a keyboard remap function that 
allows the user to modify the default 
keyboard layout in a 3270 terminal 
emulation session. The remap facil¬ 
ity supports key swapping, key dis¬ 
abling, and assignment of a string of 
keystrokes to a single key combina¬ 
tion (accelerator keys). With these fa¬ 
cilities, the keyboard layout can be 
arranged to be consistent with a pre¬ 
vious application, keys rearranged to 
put those most frequently used at the 
most accessible positions, or fre¬ 
quently used combinations reduced 
to a single keystroke. These func¬ 
tions all enhance productivity. 


3270 Emulation supports 3270 host- 
directed print, 3270 Graphics sup¬ 
port enabling, and Presentation 
Space Print (3270 local copy). 3270 
host-directed print allows (LU1, 

LU3, and non-SNA) printer data 
streams to be printed at the worksta¬ 
tion printer. Multiple printer sessions 
are supported. 3270 Graphics sup¬ 
port works with the GDDM-OS/2 
Link program product which adds 
graphics support to the 3270 emula¬ 
tor. This allows the workstation to 
function as a GDDM mainframe 
graphics terminal. In addition, 
GDDM pictures may be printed and 
plotted or saved to a Presentation 
Manager metafile. Presentation 
Space Print may be either host- or 
user-initiated. The entire Presenta¬ 
tion Space or a user-selected portion 
may be printed. All these facilities 
extend the scope of the workstation 
to participate in graphics- or print- 
oriented applications in addition to 
interactive ones. 

In summary, 3270 Emulation sup¬ 
port provides all the essential func¬ 
tion of the 3270 terminals and also 
adds many more functions from the 
OS/2 platform. 

ASCII Terminal Emulation: Two 

ASCII terminal emulators are pro¬ 
vided. OS/2 workstations connected 
through an asynchronous link to a 
suitable host can emulate either of 
these terminals: IBM 3101 (Model 
20) and DEC VT100. 

These terminal emulators provide: 

• Asynchronous access to a Sys¬ 
tem/370 or System/390 host 
through a protocol converter 

• Access to other IBM or non-IBM 
hosts that support either IBM 
3101 or DEC VT100 terminals 

• Access to a range of network data 
services, such as news, mail, and 
other online information services. 


The asynchronous link can be 
switched, leased, or direct, and is 
compatible with the 1984 CCITT 
V24/V28 (RS232C) recommenda¬ 
tions as implemented by IBM. Multi¬ 
ple asynchronous sessions can be 
configured, and up to three asynchro¬ 
nous ports may be used. However, 
only one ASCII terminal emulation 
session can be active at any one 
time. The active asynchronous ses¬ 
sion runs in its own OS/2 panel. 

The ASCII terminal emulators sup¬ 
port 7-bit (any parity) and 8-bit (no 
parity) asynchronous character data 
streams. The modem command 
strings provided for the explicitly 
supported modems, or their equiva¬ 
lents, may be edited by the user. 

This allows support for a variety of 
modems with different commands. 

It is also possible through the use of 
a single key to have a “snapshot” 
copy of the display screen contents 
saved on a logfile. An “ABC” 
switch can be connected to any asyn¬ 
chronous communications port to 
provide user switching between a 
modem and other serial I/O devices 
(such as printers and plotters). The 
port is shared on a sequential use 
basis. 

File transfer is supported and occurs 
through the active asynchronous ter¬ 
minal emulator session; therefore, 
only one asynchronous file transfer 
can be active at a time. However, 
the asynchronous file transfer can be 
concurrent with 3270 file transfers. 

There are three ways that files can 
be transferred: 

• Asynchronous file transfer to an 
IBM host 

When an ASCII terminal emula¬ 
tor is running via a protocol con¬ 
verter to a System/370 host, files 
can be transferred using the IBM 
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3270 PC File Transfer Program. 
This program includes 4-byte 
CRC error detection. The host 
must be running MVS/TSO, 

VM/CMS, or VSE/SP and the file 
transfer program must be installed 
and accessible. 

• Asynchronous transfer of files 
using the XMODEM protocol 

Files can be transferred using 
XMODEM protocol to any other 
workstation that supports this pro¬ 
tocol, whether IBM or non-IBM. 
The remote workstation must 
have a suitable file transfer pro¬ 
gram loaded when the file trans¬ 
fer is initiated, and the transfer is 
in 128-byte blocks with one byte 
checksum error detection. 

• Asynchronous file transfer using 
“Send ASCII Text File” 

ASYNC terminal emulation can 
be used to send ASCII data from 
a file, in addition to placing re¬ 
ceived data into a file. 

The default keyboard layouts for 
3101 terminal emulation or VT100 
terminal emulation can be changed 
through a remap procedure similar 
to that for 3270 terminal emulation. 
The procedure supports key swap¬ 
ping, key disabling, and assignment 
of a string of keystrokes to a single 
key combination. Also the clipboard 
functions of mark and copy are pro¬ 
vided by Presentation Manager. 
These functions allow data to be 
transferred from the ASCII terminal 
emulation window to another appli¬ 
cation. Simple text, text with attrib¬ 
utes, and bit images are supported 
for these editing commands. 

In summary, the ASCII emulation 
support provides basic ASCII termi¬ 
nal and file transfer capability. It can 
also support ASCII applications and 
has an associated API, known as the 


Asynchronous Communications De¬ 
vice Interface (ACDI). The ACDI 
characteristics are described in the 
API section. 

Both the 3270 and ASCII terminal 
emulators use the Presentation Man¬ 
ager and its windowing facilities to 
allow user interaction with the sys¬ 
tem and to take advantage of the 
online choice of fonts for most dis¬ 
plays. Each logical terminal appears 
in a separate window, which can be 
individually started, stopped, moved, 
and sized by the user. Window char¬ 
acteristics can be saved for future 
use. Because the operating environ¬ 
ment can be tailored to suit individ¬ 
ual user preferences, users achieve 
greater productivity. 

5250 Work Station Feature and 
Support for the AS/400 and 

System/36: The 5250 Work Station 
Feature (WSF), provided by Commu¬ 
nications Manager, allows an OS/2 
workstation to be used in place of a 
5250 terminal or printer, or both. 
Support is provided for connections 
to an AS/400 or System/36 for 5250 
WSF application programs. These 
applications may be used unaltered 
or they may be enhanced through 
the use of EHLLAPI in a manner 
similar to that used with 3270. 
EHLLAPI supports additional func¬ 
tions that can be called from an 
OS/2 program. (Refer to the API 
section for more details.) 

The 5250 WSF program supports 
the functions of 5250 display termi¬ 
nals and printers. It supports ses¬ 
sions that make the workstation 
appear as an IBM 3196 or 3197 dis¬ 
play terminal. A full-screen environ¬ 
ment is used for the display. Printer 
sessions emulate the functions of a 
5256, 5224, or 5219 host printer on 
many OS/2 workstation printers. A 
combination of up to five display or 
printer sessions is supported concur¬ 


rently. All of these sessions do not 
have to be with the same host, but 
can be with any combination of 
AS/400s and System/36s in the 
network. 

Communications to the AS/400 Sys¬ 
tem allow IBM Token-Ring, X.25, 
Twinaxial, and remote connection 
via the IBM 5294 Remote Control 
Unit links, in addition to SDLC 
links. System/36 supports X.25, 
SDLC, and IBM Token-Ring. All 
these use LU6.2 protocols. 

Unlike the other two terminal emula¬ 
tors under Communications Man¬ 
ager, 5250 WSF does not support 
file transfer between the workstation 
and the host computer. However, 
file transfer support is available us¬ 
ing the AS/400 PC Support Program 
(release 2.0 or later) on an AS/400 
or System/36 host. The AS/400 PC 
Support Program also provides 
shared folders, virtual printer, text as¬ 
sistance functions, and other useful 
facilities. Shared folder support al¬ 
lows workstation files and programs 
to be stored on the host disk and ac¬ 
cessed as a normal workstation disk 
drive. Virtual printer allows output 
from workstation programs to be 
printed on host printers. Text assis¬ 
tance functions are required when us¬ 
ing the AS/400 Office functions on 
a workstation. The AS/400 PC Sup¬ 
port program should be installed if 
the user needs these functions. 

The 5250 WSF program allows the 
AS/400 and System/36 terminals to 
be replaced with PS/2s. The use of 
PS/2s brings the power of the work¬ 
station directly to the operator. This 
support may be in operation simulta¬ 
neously with other CM applications 
and emulators. Many organizations 
use IBM mid-range systems such as 
the AS/400 for their departmental 
host and System/370s for headquar¬ 
ters functions. The CM enables them 
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to interact with both hosts simultane¬ 
ously in order to be responsive to 
business demands. 

LAN Gateways 

In the LAN environment, individual 
workstations do not need their own 
communications adapters and mo¬ 
dems. They can share those of a 
“gateway.” A gateway is a separate 
box on the LAN that directs the data 
traffic passing through it from work¬ 
station to host (or another system) or 
vice versa. CM workstations can ac¬ 
cess gateways to System/370 archi¬ 
tecture hosts, other hosts supporting 
LU6.2 protocols, and ASCII hosts. 

By using a gateway, line and mo¬ 
dem costs can be reduced. 

Traditionally, access to a Sys¬ 
tem/370 host has been via a control¬ 
ler such as the 3174, which acts as a 
concentrator or a gateway. In the 
LAN environment, CM provides 
gateway functionality within the 
PS/2. The CM SNA Gateway sup¬ 
port allows access to an IBM Sys¬ 
tem/370 host by multiple users 
attached to the gateway via an IBM 
Token-Ring, IBM PC Network 
LAN, ETHERAND LAN, SDLC 
switched link, or an X.25 network. 
The link between the gateway and 
the host may be SDLC, X.25, or an 
IBM Token-Ring. 

The gateway PS/2, which does not 
have to be dedicated to the gateway 
task (in contrast to the controllers), 
appears to the host as a single physi¬ 
cal unit (PU2.0) with up to 254 logi¬ 
cal unit (LU) sessions that may be 
shared among the workstations. Up 
to 256 workstations may be config¬ 
ured on the LAN, with 64 active at 
one time, each with multiple LUs. 
(Note that IBM plans to increase the 
number of active workstations.) The 
workstation appears to the user as if 
it were directly attached to the host. 


LUs may be pre-assigned to worksta¬ 
tions; or they may be “pooled” to 
allow greater efficiency in their allo¬ 
cation among workstations, and to 
reduce the configuration and start up 
requirements in the host. The proto¬ 
cols supported by the gateway be¬ 
tween the workstation and the host 
are LUO (often used in specialized 
industry applications), LUs 1, 2, and 
3 (which represent 3270 operations), 
and LU6.2, which is the strategic dis¬ 
tributed processing protocol. 



CM workstations can 
access gateways to 
System/370 architecture 
hosts, other hosts 
supporting LU6.2 
protocols, and ASCII 
hosts. 


In most environments, LAN worksta¬ 
tions may use the same gateway 
when operating with: 

• OS/2 EE 

• IBM Personal 
Communications/3270 

• 3270 Emulation Program 
Version 3.0 

• 3270 Workstation Program 
Version 1.1 

• APPC/PC Version 1.11 

In summary, use of the CM gateway 
provides an efficient way to allow 
workstations to communicate with 
the System/370 host. In fact, it is so 
efficient internally that in many sce¬ 
narios the workload associated with 
the gateway function will leave am¬ 
ple capacity for other services to be 


accomplished on the same system. 
LAN Server or Database Server are 
likely candidates to be used there. 
The use of a gateway does not dis¬ 
rupt applications written for a direct- 
connect environment, provided the 
user system is properly configured. 

Communications Manager does not 
provide a LAN APPN gateway to 
other IBM hosts; but a complemen¬ 
tary product - the IBM SAA Net¬ 
working Services/2 program (NS/2) 

- may be used in this capacity. By 
configuring the gateway as a PU2.1 
node, links may be established to 
any IBM system supporting LU6.2 
protocols. This allows LU6.2 ses¬ 
sions between the LAN workstation 
and the host. For example, the 5250 
WSF could be used on the worksta¬ 
tion through the gateway to an 
AS/400. In the future, IBM plans to 
make all the function of NS/2 avail¬ 
able directly within CM. 

For asynchronous connection to off- 
LAN hosts, databases, and services, 
a CM-based workstation can use the 
dial-out capabilities of the IBM 
LAN Asynchronous Connection 
Server (LANACS) Version 2.0. This 
provides line- and modem-pooling 
facilities for OS/2 EE and DOS 
workstations with the appropriate 
level of support. In this case the 
DOS-based LANACS gateway does 
have to be dedicated to the gateway 
function. Note also that the OS/2 
workstation can use it only to dial 
out from the LAN; a remote OS/2 
workstation cannot dial in. 

Application Programming 
Interfaces (API) 

CM has several APIs used by the 
OS/2 communications facilities and 
available to the application program¬ 
mer. These APIs support a wide vari¬ 
ety of communication functions 
between workstations and hosts, as 
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well as between LAN workstations 
functioning as servers or requesters. 

The EHLLAPI interface provides 
programming access to the worksta¬ 
tion applications of 3270 terminal 
emulation or the 5250 Work Station 
Feature. EHLLAPI allows complex 
functions to be manipulated under 
program control, while the user sees 
the process as a single function. In 
this way, interactions with the host 
can be simplified and made easier to 
use. Another advantage of 
EHLLAPI is that data can be proc¬ 
essed before being transmitted to the 
host application, thereby taking 
advantage of the power of the 
intelligent workstation. 

EHLLAPI can also be used to per¬ 
form an automatic logon, to inter¬ 
cept and respond to host messages, 
or to translate keystrokes into more 
complex requests. This interface can 
currently be called from IBM C/2, 
COBOL/2, PASCAL/2, BASIC/2, 
and Macro Assembler/2 languages. 
IBM plans to enhance EHLLAPI 
and increase flexibility by allowing 
more than one program to access it 
simultaneously, including calls from 
DOS programs running in one of the 
Multiple Virtual DOS machines un¬ 
der OS/2 SE 2.0. Also, the interface 
itself is planned to be extended to 
support structured fields that will 
facilitate such operations as file 
transfer. 

APPC, together with its SAA coun¬ 
terpart, CPI-C, is IBM’s strategic 
API to provide distributed transac¬ 
tion processing capabilities. An 
APPC application consists of two 
programs, usually at different SNA 
nodes, that cooperate to carry out a 
particular processing function. Both 
programs can exchange data and 
thus share each other’s local re¬ 
sources such as processor cycles, da¬ 
tabases, and work queues, as well as 


each other’s physical components 
such as keyboards and displays. 

APPC uses the LU6.2 interface archi¬ 
tecture. The LU6.2 architecture has 
been developed to provide a peer-to- 
peer communication protocol be¬ 
tween SNA applications (intelligent 
systems). LU6.2 allows sophisticated 
communication between worksta¬ 
tions and other systems for distrib¬ 
uted function processing. 

LU6.2, as defined in the APPC archi¬ 
tecture, is a particular type of SNA 
logical unit. Each LU provides a con¬ 
nection, or port, between its applica¬ 
tion programs and the network 
resources available to its programs. 
The resources may be physical, such 
as processor machine cycles and 
disk or tape files, or logical, such as 
sessions and queues. Some of these 
resources are attached to the same 
LU as the program. Other resources 
are remotely attached to other LUs. 

APPC provides the following: 

• A programming interface for ba¬ 
sic and mapped conversations 

• A confirm synchronization level 

• Security support at session and 
conversation level 

• Multiple LUs 

• Parallel sessions with the ability 
to change the number of sessions 
with remote systems 

• Concurrent multiple links 

Currently, APPC applications under 
OS/2 EE cannot utilize a coaxial at¬ 
tachment to a 3x74 controller. IBM 
plans to enhance support for OS/2 
workstations COAX-attached to a 
suitably configured 3174 to allow 
APPC applications to run over the 
COAX link. These applications will 
be able to communicate to other 
workstations similarly attached to 
the 3174, to whom the connection 
will appear as a direct LAN link. 


The COAX-attached workstation 
can also utilize the 3174 as a gate¬ 
way to a host or a bridge to a Token- 
Ring LAN attached via the 
Token-Ring adapter. 

Note: SAA CPI-C is a variant of 
APPC that is consistent across the 
SAA family. Programs written to 
CPI-C may be easily migrated from 
one family member to another, for 
example, from an OS/2 platform to 
an OS/400 platform. CPI-C is not 
supported directly by OS/2 but is 
supported by the complementary 
product IBM SAA Networking 
Services/2. In the future, this prod¬ 
uct, which also has APPC perform¬ 
ance improvements and an extension 
to the APPC interface, is planned to 
be incorporated into Communica¬ 
tions Manager. This interface can 
currently be called from IBM C/2, 
COBOL/2, PASCAL/2, and Macro 
Assembler/2. 

SRPI: This is the programming in¬ 
terface for the Enhanced Connectiv¬ 
ity Facilities. It enables the writing 
of simple, communications-inde- 
pendent, requester programs that can 
call to host server programs, with 
synchronous returns. It is supported 
over links using LU2 protocols. 

Host server support is available un¬ 
der MVS/TSO and VM/CMS. Al¬ 
though SRPI is sufficient for a large 
number of tasks, APPC should be 
used if more extensive capabilities 
are needed. SRPI can currently be 
called from IBM C/2, COBOL/2, 
PASCAL/2, and Macro Assembler/2. 

X.25 is an SAA common communi¬ 
cations support protocol. Before de¬ 
scribing the API associated with it, 
the scope of CM support for this 
important facility will be outlined. 
OS/2 EE X.25 Packet Switched Data 
Network (PSDN) support allows a 
PS/2 (Model 50 or higher) equipped 
with one or more IBM X.25 Inter- 
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face Co-Processor/2 adapters to at¬ 
tach to one or more X.25 PSDNs 
and communicate with other systems 
or hosts having appropriate X.25 sup¬ 
port. Connection to public and pri¬ 
vate networks conforming to CCITT 
1980 or 1984 X.25 recommenda¬ 
tions is supported. Multiple IBM 
X.25 Interface Co-Processor/2 adapt¬ 
ers are supported, depending on the 
available slots in the system unit. 

The software enables each adapter to 
offer either an X.21, X.21bis/V.24, 
or an X.21bis/V.35 interface, and 
support speeds up to 64K bps. The 
software can support a mixture of up 
to 128 Switched Virtual Circuits 
(SVC) and Permanent Virtual Cir¬ 
cuits (PVC). SNA Communications 
is supported by the Qualified Logi¬ 
cal Link Control (QLLC). 

X.25 Non-SNA API: This interface 
at OSI level 3 provides facilities for 
appropriately programmed non-SNA 
Data Terminal Equipments (DTEs) 
to communicate with each other 
across one or more X.25 connec¬ 
tions. Both SNA and non-SNA com¬ 
munications are possible over the 
same physical link, and up to 40 
X.25 applications (SNA and non- 
SNA) can execute concurrently in a 
single workstation. The interface is 
currently supported by IBM C/2, 
PASCAL/2 and Macro Assembler/2. 
Thus the API allows non-SNA (in 
addition to SNA) applications to op¬ 
erate over the X.25 PSDNs. 

ACDI: This interface is provided to 
allow the writing of applications 
(such as asynchronous emulators or 
file transfer programs) to exchange 
data over asynchronous links. The in¬ 
terface provides a high degree of in¬ 
dependence from the asynchronous 
hardware used. Device-specific pro¬ 
gramming modules are required for 
each supported device type and are 
included in the product. They are 
transparent to user applications. Sup¬ 


ported functions include the ability 
to manipulate the line characteristics 
and connection control (connect and 
disconnect) without having to deal 
with physical device-specific 
characteristics. 

ACDI may be used to manipulate 
modem command strings to custom¬ 
ize and automate dialing procedures, 
or to use an alternate modem. One 
ACDI application can share a V.24 
(RS232C) ABC switch with serial 
devices such as printers or plotters. 
Recent enhancements allow the redi¬ 
rection of ACDI calls (across a 
LAN) to an ASYNC gateway, for ex¬ 
ample. This is currently done from 
the command line but IBM plans to 
make it accessible from programs 
for greater flexibility. ACDI is cur¬ 
rently supported by IBM C/2, PAS¬ 
CAL/2, and Macro Assembler/2. 

Local Area Network (LAN) 
Programming Interfaces: Both 
IEEE 802.2 and IBM NetBIOS are 
supported for program-to-program 
communications. The IEEE 802.2 
protocol is a lower-level communica¬ 
tions interface. The APPC support 
provided by CM uses the IEEE 
802.2 interface to access the LAN. 
Application programmers may ac¬ 
cess the IEEE 802.2 API for greater 
control where higher performance is 
critical. The NetBIOS programming 
interface provides an additional inter¬ 
face for communication across a 
LAN. NetBIOS is a name-oriented 
program-to-program interface that 
may be used for application re¬ 
stricted to the LAN environment. 

The NetBIOS protocol can be used 
concurrently with the IEEE 802.2 
LAN access. Both of these APIs are 
currently supported by IBM C/2, 
PASCAL/2, and Macro Assembler/2. 

IBM plans to restructure the OS/2 
LAN Transport function to improve 
the performance and resource utiliza¬ 


tion. The Network Device Interface 
Specification (NDIS) will be pro¬ 
vided to support high performance 
media access control device drivers 
for Token-Ring, Ethernet, PC Net¬ 
work, and LAN Over Coax connec¬ 
tivity. In addition, new NetBIOS and 
802.2 protocols will be included that 
support the NDIS interface and pro¬ 
gramming interfaces, and provide 
performance improvements. 

Conventional LU Application 
(LUA) Interfaces: These may be 
used for: 

• Communications support for LUO 
terminal functions 

• A migration path for LUO-based 
applications 

• Workable replacements for 
LUO-based control units 

• Base communications for LUO, 1, 
2, and 3 emulators (this is in addi¬ 
tion to the LU1, 2, 3, and 6.2 sup¬ 
port already available in 

OS/2 EE) 

The LUO protocol allows greater pro¬ 
gramming flexibility than the other 
supported LUs and has been widely 
used in the finance and retail indus¬ 
tries. The recommended protocol for 
future applications is LU6.2. CM 
support for LUO is to allow existing 
programs to continue operating dur¬ 
ing the migration period. 

LUO communication is enabled 
through the use of two programming 
interfaces. The Session Level Inter¬ 
face (SLI) is a higher level data 
stream interface that will normally 
be used by customer applications. 

The SNA Request Unit Interface 
(RUI) is at a lower level and is in¬ 
tended for system programming but 
is also available for customer use. 
Programming language support for 
both SLI and RUI is currently from 
the IBM C/2, COBOL/2, PASCAL/2 
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and Macro Assembler/2 compilers. 
Collectively, SLI and RUI are re¬ 
ferred to as conventional LU applica¬ 
tion (LUA). 

Common Services Interface: 

CM provides functions for gathering 
and processing problem determina¬ 
tion data. These functions include 
tracing of programming interfaces, 
data units, and/or system events; dis¬ 
playing and printing of all or se¬ 
lected error logs from file; system 
dumping; and displaying of all or se¬ 
lected message logs. These services 
can be invoked from the console or 
via a Common Services API, which 
allows all these Communications 
Manager RAS functions (trace, 
dump, errors, and messages) to be 
performed under program control 
and not require an operator. A 
user-written program can monitor er¬ 
rors and messages selectively, and 
take appropriate action. Message 
pop-ups on the screen can be sup¬ 
pressed. The same API also supports 
ASCII/EBCDIC conversions, code 
pages conversion, and the transferals 
of diagnostic data to a host. For ex¬ 
ample, applications can use this serv¬ 
ice to alert a NetView® operator of 
conditions requiring action. 

Subsystem Management Interface: 

CM allows a system administrator to 
control and obtain status information 
on the SNA communication re¬ 
sources maintained by CM. As a 
management tool, it displays the pro¬ 
grams being used, the sessions being 
used by the programs, detailed infor¬ 
mation about the sessions, and re¬ 
sources that are active. It allows the 
activation or deactivation of sessions 
and data link controls. It also can be 
used to start and stop an attach man¬ 
ager that allows applications to be re¬ 
motely started. These services are 
invoked in some cases from the con¬ 
sole and in others via an API, as ap¬ 
propriate. 


Installation and 
Configuration 

Configuring (tailoring the required 
components) and installing Commu¬ 
nications Manager is accomplished 
by one of several options. 

The Custom Install option enables 
the system or network administrator 
to design an installation diskette that 
installs only those components and 
features required at each worksta¬ 
tion. A Custom Install diskette also 
provides the configuration file 
needed for the installed components 
and features. This option is particu¬ 
larly beneficial to novice users or 
when installing OS/2 Extended Edi¬ 
tion on multiple workstations, be¬ 
cause it allows the installation to be 
completed with minimal user interac¬ 
tion. Because each user does not 
need to have all the functions in¬ 
stalled, the amount of memory and 
disk storage required at the worksta¬ 
tion can be reduced. 

The Basic Configuration Services op¬ 
tion assists users who do not have 
the support of a system administra¬ 
tor and who are relatively inexperi¬ 
enced in communications. It helps 
them install the program and have it 
running for a number of communica¬ 
tions environments. Basic Configura¬ 
tion Services may be used for one or 
more of the following: 

• 3270 emulation, directly con¬ 
nected via SDLC, LAN, or DFT 

• 5250 Work Station Feature con¬ 
nected via Twinax, SDLC, or 
LAN (Token-Ring only) 

• ASCII emulation to single host 

• Database Manager’s Remote Data 
Services configuration between 
one OS/2 Database Requester and 
Server 

Basic Configuration Services may 
be supplemented with Advanced 


Configuration Services to cover 
other environments and additional 
Remote Data Services connections 
as required. 

For those not using a Custom Install 
diskette or Basic Configuration Serv¬ 
ices, a process known as the Ad¬ 
vanced Installation can be used. 

With Advanced Installation, the com¬ 
ponents and features are selected in 
a certain sequence. In addition to 
permitting the selective installation 
of various OS/2 components, the in¬ 
stallation program allows the addi¬ 
tion, removal, or reinstallation of 
OS/2 components and features at 
any time after the initial installation 
has been completed. 

Finally, for system administrators 
with large numbers of similarly con¬ 
figured workstations, a Batch Con¬ 
figuration utility is provided. Basic 
or Advanced Configuration is used 
first to establish an individual repre¬ 
sentative prototype configuration 
file. Then, the system administrator 
creates an ASCII file that contains 
the essential differences between in¬ 
dividual end users. This file and the 
prototype are processed by the util¬ 
ity to build a configuration file for 
each user. The support allows the 
creation, modification, and deletion 
of a subset of the parameters for the 
profiles in the following areas: 

• Workstation Profile 

• 3270 

• SNA/APPC 

• SDLC 

• Twinax 

• X.25 

• SNA Network 

• SNA Gateway 

• LUO 

• 802.2 

• NetBIOS 
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Typically, the files would be gener¬ 
ated under program control for use 
with the Custom Install option or 
one of the more automated forms of 
install offered by complementary 
program products such as Net- 
View/DM and the SAA Delivery 
Manager. 

IBM plans to open up the entire 
configuration file to programmed 
access, to further facilitate the con¬ 
figuration and installation of large 
numbers of workstations. 

Network Management 

CM provides extensive network 
management support. 

When errors occur at the worksta¬ 
tion level, messages can be sent to 
the operator and are logged for sub¬ 
sequent analysis. Trace and dump fa¬ 
cilities are provided as diagnostic 
tools. Online help is available to as¬ 
sist in local problems resolution, or 
to suggest contacting an administra¬ 
tor or service coordinator as 
appropriate. 

At the LAN level, network manage¬ 
ment may be facilitated by the IBM 
LAN Manager Version 2.0. This pro¬ 
gram uses CM for sending and re¬ 
ceiving information across the LAN 
and monitors the activity and status 
of the workstations and the links. An 
alternative approach is to use Net- 
View PC when NetView PC is 
installed. 

With wide area network links and a 
System/370 or System/390, the IBM 
NetView program at the host com¬ 
puter can be used. This provides a 
central point for control. CM sup¬ 


ports a Net View-managed network 
by automatically forwarding alerts 
generated by the hardware or soft¬ 
ware associated with data links. Sup¬ 
port for SDLC, asynchronous, 
Token-Ring, ETHERAND, PC Net¬ 
work, twinaxial, and X.25 connec¬ 
tions is included. CM requires 
APPC to be installed on each work¬ 
station for the forwarding of alerts, 
and the links to the host must be 
SDLC or Token-Ring. 

The NetView operator can also re¬ 
quest vital product data pertaining to 
the workstations, such as machine 
type, serial and model number, and 
the name, version, release, and modi¬ 
fication of the installed OS/2 EE 
software components. 

Exchanges with the NetView host 
are accomplished by the Common 
Services Interface (CSI). This is a 
published programming interface 
that can be used by user applications 
to notify (through the alert mecha¬ 
nism) a central monitoring facility. 
The CSI may also be used to re¬ 
motely invoke diagnostic tools, such 
as running traces and dumps, with¬ 
out involving the workstation user. 

IBM plans to extend this support to 
allow the NetView operator (or a 
program at the NetView host using 
CLISTs or REXX execs) to issue 
most OS/2 commands remotely for 
execution at the PS/2. This will pro¬ 
vide powerful manipulative and 
LAN management capabilities from 
the host. 

In APPC application environments, 
subsystem management is provided 
to the system administrator to con¬ 


trol and obtain status information on 
the resources maintained by CM. It 
allows the activation and deactiva¬ 
tion of sessions, and supports the re¬ 
mote starting or stopping of the 
attach manager. 

Conclusion 

Communications Manager is IBM’s 
strategic workstation-based commu¬ 
nications offering. It is accepted as 
the platform of choice by many IBM 
workstation-based products, includ¬ 
ing OSI/CS, TCP/IP, CICS, and Of¬ 
fice Vision. CM is designed for use 
within the SAA framework. It pro¬ 
vides many concurrent networking 
capabilities, which represents signifi¬ 
cant productivity savings for both de¬ 
velopers and users. CM is the 
development and distributed process¬ 
ing workstation communications plat¬ 
form for the 1990s. 
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Improving OS/2 

Application 

Performance 

Mark W. Brooks and 
Gary S. Kaufman 
IBM Corporation 
Markham , Ontario , Canada 

This is a project history. It de¬ 
scribes the experiences of a team 
assembled to improve the perform¬ 
ance of an OS/2 application under 
development. 

The development team of a medium- 
size (45 KLOC) OS/2 project identi¬ 
fied performance as a problem that 
would inhibit satisfaction with the 
product. 


Performance goals were set for the 
product using usability studies and 
other benchmarking information. At 
the highest level these goals were to: 

• Reduce the elapsed time taken to 
perform the most important prod¬ 
uct functions 

• Reduce the amount of system re¬ 
sources used by the application 

A performance team was formed 
that achieved a significant perform¬ 
ance improvement: an overall reduc¬ 
tion in elapsed time of more than 
300 percent across the product, and 
as much as 600 percent in several 
instances. 

While the performance team worked 
in a specialized OS/2 environment, 
and the following is specific to that 


environment, the information pre¬ 
sented in this discussion might prove 
valuable to any technical group con¬ 
cerned with performance issues. 

Objectives 

To reduce performance problems, 
the team believed it was necessary 
to minimize memory working set 
and maximize speed. 

Memory Working Set: Memory 
working set is the minimum amount 
of memory required to run a particu¬ 
lar scenario without frequent swap¬ 
ping and still achieve acceptable 
performance. 

This means a given working set 
measurement is always scenario- 
dependent. The size of the applica¬ 
tion’s working set was one of the 
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key factors in its overall 
performance. 

The working set of an application 
consists of a series of code and data 
segments that need to be loaded into 
memory while a function is execut¬ 
ing. In OS/2, a code segment is nor¬ 
mally loaded into memory when a 
function in the code segment needs 
to be executed by the process. Once 
the function in the code segment has 
finished executing, the operating sys¬ 
tem can discard the segment if it is 
short of memory. Therefore, the 
larger the working set of the applica¬ 
tion, the more likely it will need to 
discard and reload code segments 
into memory from the much slower 
fixed disk. When the operating sys¬ 
tem does not have enough memory 
to hold all the code segments, it will 
be forced to constantly load and dis¬ 
card code segments. This situation is 
called “overcommitment” (or thrash¬ 
ing) and can affect the performance 
of not only the application causing 
the problem but any other applica¬ 
tion that may be running. 

A similar problem occurs with data 
segments; however, instead of being 
discarded, a data segment is written 
out to and, when required, reloaded 
from the OS/2 swapper file. There¬ 
fore, a swapped data segment is at 
least twice as costly, in terms of disk 
I/O, as a similiarly sized code 
segment. 

Measuring Memory Working Set: 

The MAP file produced by the OS/2 
linker provides: 

• An approximate size of your code 
and data segments 

• An idea of the maximum possible 
size of an application’s working 
set 

• A list of the size and type of appli¬ 
cation segments that could be 
loaded into memory 


Using the sum of these application 
segments, as well as the size of any 
data segments allocated dynamically 
within the program, it is possible to 
calculate the maximum possible 
amount of memory required by an 
application to run without swapping 
or reloading. It is unlikely that this 
maximum memory requirement will 
be reached as only a fraction of the 
total code and data segments should 
ever be loaded at once in a well- 
structured application. 

The working set calculation is more 
complicated if multiple processes 
are sharing code or data segments. 

In general, the following rules apply: 

• If multiple copies of an applica¬ 
tion are loaded and running simul¬ 
taneously, only one copy of each 
code segment is loaded and 
shared between the processes 

• Even if a code segment is marked 
as unshared, the code segment is 
still shared 

• On the other hand, multiple ver¬ 
sions of a data segment are 
loaded unless it is marked as 
“read-only” or non-shareable 

To get a more accurate working set 
measurement, the performance team 
used an IBM internal tool with func¬ 
tions similar to IBM System Per¬ 
formance Monitor/2 (SPM/2) 

Version 1.0. 

In summary, the larger the working 
set of an application, the longer it 
takes to run. An application with a 
large working set also affects the 
speed of other executing applications. 

Strategies for Improving 
Performance 

Because the opportunity to improve 
performance came so late in the de¬ 
velopment cycle, the performance 
team was restricted by time limita¬ 


tions. Therefore, the team initially fo¬ 
cused on problems with the most 
commonly used code. 

Identifying Problems: The first 
step towards performance improve¬ 
ment is to identify the bottlenecks in 
the code. To do this, the perform¬ 
ance team used several tools: 

• Simple file dump 

First, the team used a simple file 
dump system. In this system, a 
statement was inserted at the en¬ 
try point of every function and at 
every exit point throughout the en¬ 
tire function. The entry dump 
wrote the name of the function 
and an identifying number and 
started a timer for that entry 
point. The exit point ended the 
timer and wrote the function 
name and elapsed time to the 
dump file. 

These trace dumps identified: 

— How often each function was 
likely to be called, thereby al¬ 
lowing the performance team 
to concentrate on the critical 
code. 

— The elapsed time for each func¬ 
tion call. While this was some¬ 
what inaccurate, it helped 
identify heavy processing rou¬ 
tines and helped indicate the 
success of the tuning 
techniques. 

The data from this type of trace 
system provided a good enough 
base for many of the initial per¬ 
formance decisions. 

• Complex Tracing 

The team also tried a more sophis¬ 
ticated IBM internally used trac¬ 
ing system with features similar 
to IBM SPM/2 Version 1.0. This 
system gives a precise timing 
breakdown for a long sequence of 
actions and their related function 
calls. Because of the complexity 
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of this trace data we found it par¬ 
ticularly useful when analyzing 
an already identified problem. 
Similar systems are also available 
from non-IBM sources. 

Once the problems were identified, 
the team decided to meet its perform¬ 
ance goals by “fine-tuning” existing 
code, and by redesigning part of the 
product. 

Reducing the Memory Working 

Set: It is important to maintain the 
working set at the lowest possible 
level to control and improve the 
speed of the application. For exam¬ 
ple, for the first few releases of the 
product, the overall working set was 
extremely large. Therefore, even on 
a loaded 16 MB PS/2, the applica¬ 
tion could easily slip into a condi¬ 
tion known as thrashing (constantly 
accessing the hard disk to load or 
swap code/data segments). 

To reduce the memory working set, 
the performance team looked at re¬ 
structuring code/data segments and 
tuning dynamic memory allocation 
and usage. 

Improving Speed: To improve 
speed, the performance team 
examined: 

• “Traditional” code tuning 

• OS/2 tuning 

• Database tuning 

Later sections on tuning will discuss 
these areas in detail. 

Design Considerations 

The design of an application is the 
most important influence on perform¬ 
ance. During the low-level design 
phase of the application develop¬ 
ment cycle, performance must be 
considered when making design 
decisions. 


If an application’s design inherently 
dictates poor performance, no 
amount of code tuning will save it! 

Traditional Code Tuning 

The goals of code tuning are to: 

• Decrease the number of processor 
cycles required by the program 

• Decrease the number of address 
calculations performed 

• Decrease the number of memory 
fetches 

• Decrease the size of the object 
code 

Traditional optimization deals with 
improving the compiler translation 
of C code into the machine language 
end product. 



Aligning data structures 
can make significant 
performance 
improvements to an 
application. 


Because development environments 
and compilers are now more sophisti¬ 
cated, some of these methods may 
be automatically implemented by the 
compiler. 

If implemented correctly, the follow¬ 
ing suggestions should not affect the 
clarity of the code and should in¬ 
crease the speed of any application 
running on a PC AT or PS/2. 

Structural Alignment: Aligning 
data structures can make significant 
performance improvements to an ap¬ 
plication. Some measurements show 


that by simply aligning an applica¬ 
tion’s structures, the speed of mem¬ 
ory accesses can increase as much 
as 25 percent over that with un¬ 
aligned structures. 

Structural alignment is so effective 
because, in many cases, the number 
of memory accesses required for an 
operation is cut in half. This is be¬ 
cause a memory fetch retrieves four 
bytes of data at a time, aligned on 
four-byte boundaries. Therefore, if a 
four-byte pointer is to be retrieved 
and the structure was aligned, the 
pointer could be retrieved in one 
memory fetch instead of two. 

The requirements for aligning struc¬ 
tures are as follows: 

• The structure has a starting ad¬ 
dress on a four-byte boundary 

• Every element in the structure 
that is four bytes or fewer in size 
does not cross a four-byte word 
boundary 

• The structure elements that are 
greater than four bytes should be 
started on a four-byte word 
boundary 

Figure 1 shows examples of un¬ 
aligned and aligned structures. 

Data Conservation: In most cases, 
it is advisable when creating data 
tables or retrieving data from a LAN 
server or flat file, to hold this data in 
memory for as long as possible be¬ 
cause LAN communications (and 
disk I/O) are very expensive in 
terms of elapsed time. 

For example, the given product in¬ 
volved a client-server architecture, 
and in the initial design two round 
trips to the server were made when 
in many cases, one would have been 
sufficient (with a minor design 
change). 
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Example of an unaligned structure: 


struct 

nonal{ 




i nt 

one; 

/* 

two bytes in size 

*/ 

1 ong 

two; 

/* 

four bytes in size 

*/ 

i nt 

*three; 

/* 

four bytes in size 

*/ 

1 ong 

} 

four; 

/* 

four bytes in size 

*/ 

Example of the above structure as an aligned structure: 

struct 

all 




1 ong 

two; 

/* 

four bytes in size 

*/ 

i nt 

*three; 

/* 

four bytes in size 

*/ 

1 ong 

four; 

/* 

four bytes in size 

*/ 

i nt 

one; 

/* 

two bytes in size 

*/ 

i nt 

} 

buf 1; 

/* 

two bytes in size 

*/ 

or 





struct 

all 




i nt 

one; 

/* 

two bytes in size 

*/ 

i nt 

buf 1; 

/* 

two bytes in size 

*/ 

1 ong 

two; 

/* 

four bytes in size 

*/ 

i nt 

*three; 

/* 

four bytes in size 

*/ 

1 ong 

} 

four; 

/* 

four bytes in size 

*/ 


To solve this problem, the team con¬ 
structed a refresh cache that cached 
some of the server data in certain in¬ 
stances, thereby doubling the speed 
of many major functions. 

Register Variables: Tagging a vari¬ 
able as a register variable essen¬ 
tially tells the compiler which 
variables are most commonly used. 
This allows the compiler to preload 
several CPU registers with com¬ 
monly used data. 

The variables most commonly 
tagged were the pointers used to 
access the major data structures 
throughout a module. Making this 
pointer a register variable eliminated 
the need to load the pointer from 
memory each time a structure ele¬ 
ment was referenced. Making this 
pointer a register variable increased 
speed by up to 20 percent in some 
routines. 

Other heavily used variables, such 
as loop counters, were also tagged 
as register variables. 

A small decrease in the size of the 
code produced by the compiler is an¬ 
other added benefit of the appropri¬ 
ate placement of register variables. 
This reduction averages about 1 per¬ 
cent for the entire application. 

Tagging a variable as a register vari¬ 
able is completely portable to other 
machine architectures. 

While some developers believe that 
the IBM C/2 compiler will properly 
place register variable tags automat¬ 
ically, the performance team felt it 
was necessary to place the tags 
manually so that no variables were 
missed. For example, any variable 
that has a pointer placed in front of 
it cannot be tagged by the compiler 
as a register variable, because if the 
compiler must take a pointer from a 


Figure 1. Unaligned and Aligned Structures 

variable, this variable must have a lo¬ 
cation in memory. To tag this vari¬ 
able as a register variable, the code 
should be modified to use a tempo¬ 
rary pointer value. 

Intrinsic Function Calls: 

It is possible to force the compiler to 
place system (library) functions in¬ 
line, rather than making a function 
call. This eliminates the overhead in¬ 
herent in function calls. 


In this product, the compiler was in¬ 
formed of what system functions to 
make intrinsic, using a set of pragma 
statements at the beginning of each 
source code file (Figure 2). 

The declaration of the intrinsic func¬ 
tions marginally increases the size of 
the final application, but it is worth 
the space if the application is mov¬ 
ing or copying small amounts of 


#1fndef CODEVIEW 

//pragma intrinsic(memcmp.memcpy.memset,strcat,strcpy,str- 
cmp,strlen) 

//pragma message(“Code now optimized for speed ”) 

//pragma loop_opt(on) 

//endi f 


Figure 2. Pragma Statements 
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memory with each strcpy or 
memcpy call. 

See the C compiler manuals for 
more detail about these statements. 

Loop Optimization: In a “for a 
while” loop, it is possible to increase 
speed by restructuring the compare 
statement of the loop. 

Comparing a variable against a num¬ 
ber or another variable requires three 
separate machine language 
instructions: 

Scenario 1 

• Load the first variable from 
memory 

• Load the second variable (or 
static number) 

• Compare the variables 

If, instead, you compare one vari¬ 
able against the value 0, the com¬ 
piler will: 

Scenario 2 

• Load the first variable from 
memory 

• Compare the variable to 0 
An example of these is: 

Scenario 1 

for (1 - 0; i < - 32; ++i) 

For this comparison the C/2 com¬ 
piler produces five assembler instruc¬ 
tions and would be slower than: 

Scenario 2 

for (1 - 32: -1 > - 0;) 

For this comparison, the C/2 com¬ 
piler produces four assembler 
instructions. 


This optimization works best for 
small, tight loops (loops that contain 
only a few statements). If the loop is 
large, the loop processing time far 
outweighs the termination condition 
processing. 

In addition, all loops should be opti¬ 
mized such that any “loop invari¬ 
ants” are moved outside of the loop. 
A “loop invariant” is something that 
does not change throughout the life 
of the loop. For example, a state¬ 
ment such as “length = 10” should 
not appear inside a loop, because it 
is completely invariant and slows 
down the entire loop by repeating 
the identical action multiple times. 

Some loop optimization was done in 
the code, but because the code did 
not contain many “tight” loops, it 
had no measurable impact on the per¬ 
formance of the application. 

Array Index Optimization: 

When using subscripts into arrays, 
for every index operation the com¬ 
piler produces assembler code that: 

• Loads the pointer to the array 

• Loads the value of the subscript 
(if it is a variable) 

• Adds the two to find the index 
variable 

It is best to avoid array subscripts 
whenever possible. This can be done 
inside loops or other situations 
where pointers and pointer arithme¬ 
tic can be used instead. 

For example: 

ford =0; i < 320; ++i) 
arrayd ) - i; 

is slower than: 

cp - &array(0); 
i = -1; 

for (j = 320; -j > = 0; ) 

*cp++ * ++i ; 


Code Path: There are several issues 
regarding code paths to consider for 
performance improvements. 

• Reduce path length 

The path length of the code is an 
important performance factor. 

The more function calls (or PM 
messages) that a particular code 
path invokes, the slower the appli¬ 
cation will run. This is because of 
the inherent overhead in function 
calls/returns and message 
processing. 

• Remove dead code 

This is code that is in the applica¬ 
tion but is never executed. This 
code increases the working set 
(and therefore decreases the 
speed) of the application. 

• Avoid identical logic 

Duplicating a function or piece of 
logic that already exists can also 
contribute to performance prob¬ 
lems. During the final code re¬ 
views for the product, several 
functions were discovered that 
duplicated, or almost duplicated, 
other existing functions. 

Return Codes: Return codes from 
both system and application calls 
should always be checked for errors. 
If, however, there is a case where 
this does not apply, then do not code 
a statement such as: 

rc - func(); 

if the return code will not be 
checked. The additional assignment 
to rc causes unnecessary statements 
to be executed and has a detrimental 
impact on performance. 

Levels of Indirection: When using 
several levels of indirection (point¬ 
ers), each pointer in the indirection 
chain must be loaded and examined 
to get to the final data item. There¬ 
fore, some CPU cycles can be saved 
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if a temporary variable is used to 
hold a data item that is repeatedly 
accessed. 

For example, if the statement 
Vcirl->var2->var3 = x; is repeat¬ 
edly executed (inside a “for” loop, 
for example), replace the statement 
with: 

pVar = &Varl->var2->var3; 


*pVar - x; 

While this type of tuning can help 
the performance of the application, 
it can also make the code harder to 
understand. 

Variable Initialization: 

Unnecessary initialization should not 
be present in application code (for 
example, filling a structure with 
nulls and then assigning values to 
most or all of the structure ele¬ 
ments). Instead of filling the whole 
structure with nulls, consider assign¬ 
ing values to each remaining field if 
you are already assigning other val¬ 
ues to most of the structure elements. 

Also remember that a character 
string only needs to have its first ele¬ 
ment initialized with a null. 

For example, if you initialize a char¬ 
acter string with strcpy(String, 
you can replace it with the following: 

String(O) = '\0'; 

- or - 

♦String = *\0'; 

Also, using as a zero-length 
string causes a pointer into the static 
data segment to be loaded, which is 
additional overhead (especially if the 
data segment is swapped out at the 
time). 


Other Techniques: Because of the 
requirements for easy maintenance 
and the ongoing development of the 
product, several code optimization 
methods were not used by the per¬ 
formance team. This does not mean 
that such approaches would not be 
valid for other projects, but simply 
that in some cases the costs out¬ 
weigh the benefits. 



When multiple small 
pieces of memory are 
required, it is far better 
to use DosAllocSeg to 
allocate a large segment 
of memory and then use 
DosSubAlloc to break this 
segment into usable 
chunks. 


Alternate methods include: 

• Supercharging - Using in-line as¬ 
sembler for key functions 

• Near pointers - Using near point¬ 
ers whenever possible to save 
memory fetches 

OS/2 Tuning 

OS/2 Memory Management: 

Minimizing the number of data seg¬ 
ments that an application creates is 
the most important consideration 
when designing an application’s 
memory management strategy. Multi¬ 
ple small segments can adversely 
affect both the application’s perform¬ 
ance and any other applications run¬ 
ning in the system. 


One of the reasons that multiple 
small segments have a negative ef¬ 
fect is that the machine’s memory 
becomes fragmented as these seg¬ 
ments get swapped out. Therefore, 
the OS/2 memory compaction algo¬ 
rithm must run more often when 
new memory is required. 

Second, if the segments are shared, 
space is reserved in every process’s 
LDT (Local Descriptor Table) for 
that segment. This causes a large 
amount of system overhead for other 
applications and possible system 
shortages due to limited LDT space. 

Flere are some important points to re¬ 
member when using OS/2 dynamic 
memory allocation: 

• Use DosAllocSeg and 
DosSubAlloc. 

When multiple small pieces of 
memory are required, it is far bet¬ 
ter to use DosAllocSeg to allocate 
a large segment of memory and 
then use DosSubAlloc to break 
this segment into usable chunks. 
This helps minimize the number 
of segments in the system. 

Another advantage of using 
suballoc is that there is only one 
segment to be freed. 

• Only use the OS/2 memory man¬ 
ager API calls to allocate mem¬ 
ory. Never use the C calls 
(Malloc, Calloc, Strdup, and so 
forth). The reason is that Malloc, 
Calloc, and Strdup each allocate 
one segment for each call, and 
you end up with a lot of small seg¬ 
ments, causing the OS/2 memory 
manager to thrash. 

Also, do not allocate a heap, be¬ 
cause Malloc and Calloc do not 
use it. 

• Allocate only the amount re¬ 
quired. A segment can always be 
“grown” (increased in size). 
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• DosAllocSeg should be a multiple 
of 4 KB up to 63.5 KB. Note: 
Suballocs can be any size. 

Never allocate more than 63.5 
KB, because a 63.5 KB segment 
is swapped (read or write) in one 
action, while a 64 KB segment 
takes two swap actions. It is ex¬ 
pected that this problem will be 
resolved with OS/2 2.0. 

• Do not use the OS/2 API call 
DosMemAvail. This call currently 
gives invalid results when OS/2 
undertakes memory compaction, 
or swapping, or the system is 
overcommitted in its memory use. 

• Memory leakage (allocating mem¬ 
ory but not releasing it when fin¬ 
ished) caused several performance 
impacts on the product. A careful 
review of dynamic memory alloca¬ 
tion and its release is always a 
good idea. Functions with multi¬ 
ple exit points are usually the 
cause of memory leaks. 

Note: Shared memory has an associ¬ 
ated usage count. All processes ac¬ 
cessing a shared segment must 
release it before the memory is freed. 

Segment Packing: For a large appli¬ 
cation, it is unlikely that all code seg¬ 
ments will be loaded into memory at 
one time. Therefore, the arrange¬ 
ment and distribution of functions 
within the code segment has a sig¬ 
nificant effect on performance. 

The linker, by default, packs the 
code into multiple segments of 64 
KB each. This causes problems 
when swapping (see comments on 
memory) and usually means that al¬ 
most all of the code segments are 
loaded into memory at once (if there 
is enough memory), giving the appli¬ 
cation the largest working set re¬ 
quirements possible. This causes 
thrashing, large swap files, and a 
slow application. 


Code segments should be managed 
as follows: 

• One segment to process messages 

• Frequently used routines grouped 
together 

• Related routines grouped together 

• Infrequently used routines 
grouped together 

• Pack segments to 4 KB multiples 

A first attempt at code segment pack¬ 
ing is to split segments along source 
code module boundaries. This can 
be accomplished as follows: 

• During the compile of each 
source module into its object file, 
specify the “/NM 
SEGMENTNAME” compiler op¬ 
tion, where SEGMENTNAME is 
the name you want to assign to 
each code segment. If you do not 
use the /NM flag, the default seg¬ 
ment name will be 
MODULE.TEXT, where 
MODULE is the name of the 
source code file. 

• List the defined segment names in 
the program’s .DEF file. For 
example: 

SEGMENTS 

FILE1_TEXT 
IN IT 

FILE2_TEXT 
FILE3_TEXT 
INITWINDOW 
BLUEMOON 


Logically grouping functions within 
the given code segments can im¬ 
prove a segment arrangement. This 
logical grouping can be accom¬ 
plished either by physically moving 
code to different source files or by 
using the pragma statements. 

If you include a pragma statement 
before the body of each function but 
after the prototype statement, the C 
compiler automatically splits the 
code into the named segment. 

In the example in Figure 3, the func¬ 
tion “error_mess” is moved from its 
default code segment (the name of 
its source code file) to the code seg¬ 
ment called “BLUEMOON.” The 
pragma statement is ifdef ed with 
the define “CODEVIEW” so that if 
the program is compiled with the 
CodeView options and the 
/DCODEVIEW define, the code is 
not moved, and CodeView is able to 
work correctly. 

The segment information at the top 
of an application’s map file, which 
is produced by the linker (if speci¬ 
fied), can be used to analyze the 
code segment packing. This informa¬ 
tion consists of a list of all the code 
and data segments and their sizes. 

DynaLink (DLL) Considerations: 

Here are some points to consider 
when using DLLs: 


#ifndef CODEVIEW 

//pragma al 1 oc_text(BLUEMOON , errorless) 
#endif 

int error mess(char *s) 

{ 

Body of function 

} 


Figure 3. Moving Code into a Named Segment 


Personal Systems/Issue 4, 1991 




30 


• Minimize the number of DLLs in 
the application. Too many sepa¬ 
rate DLLs can cause performance 
problems because each DLL (re¬ 
gardless of size) adds to: 

— The initialization time needed 
to start a process 

— The search time required to 
load a new code/data segment 

— The system resources/memory 
used as overhead 

Note: Too many help files can 
cause similar problems. 

• Do not allocate stack and heap 
segments from DLLs. A DLL al¬ 
ways uses the stack and heap of 
the calling process that is 
launched from an EXE file. Al¬ 
though a DLL’s stack and heap 
segments are never used, they are 
still packed into the DLL’s data 
group along with its static and 
global variables. Therefore, sim¬ 
ply removing the unused stacks 
from the DLL can reduce the 
working set considerably. 

• Do not declare functions that do 
not access DLL data as “expen- 
try” or “_loadds”. This unnecces- 
sarily loads the DLL’s data 
segment along with the code. 

• Set up the LIBPATH in 
CONFIG.SYS so that most used 
LIB directories are near the front 
of the search path. 

Also, do not put non-DLL files in 
LIB directories because this in¬ 
creases the system search time for 
DLLs. 

• Declare DLLs as 
LOADONCALL. This delays 
loading of a DLL from disk until 
it is actually required, thereby sav¬ 
ing memory. 

Note: This is not valid in all situ¬ 
ations, but is a guideline. 

• The caller should free DLLs 
when finished with them. 


threadfunc() 

{ 

thread body 


DosEnterCritSec(); 

DosSemClear(Wai ting„„parent_sem); 
DosExit(); 


Figure 4. Method for Freeing a Thread Stack 


This is usually true, but in some 
cases it may be better to keep the 
DLL loaded throughout the life of 
the application. 

Multitasking Considerations: 

Multitasking is an extremely power¬ 
ful feature of OS/2 that is all but ig¬ 
nored by many applications. In an 
application where concurrent pro¬ 
cessing is possible, spawning multi¬ 
ple threads (or processes, in some 
cases) can significantly increase the 
application’s performance. 

In Presentation Manager (PM) appli¬ 
cations, multiple threads are neces¬ 
sary because the main thread (thread 
1) should perform only message han¬ 
dling (no disk I/O, no semaphore 
handling, no lengthy processing). Al¬ 
lowing any of the preceding can not 
only affect performance, but can 
completely hang the system. 

Here are some points to consider in 
multitasking applications: 

• Do not create and destroy threads 
on demand. Thread and process 
spawning is expensive in terms of 
elapsed time. Wherever possible, 
create a “hot pool” of threads that 
wait for work and activate when 
required. 

• Thread priority adjustment should 
be used sparingly. Any thread can 
raise its own priority, but one- 
upmanship could occur, resulting 


in all threads executing at the 
highest priority. This gives the op¬ 
erating system no opportunity for 
proper thread management. 

• It is important to free the thread’s 
stack space when it terminates. 

The proper method for freeing a 
thread stack is shown is Figure 4. 

Note: The DosExit does an im¬ 
plicit DosExitCritSec. At that 
point, the parent thread that is 
waiting on the semaphore can 
free the thread’s stack. This proce¬ 
dure is so that the parent thread 
does not free the stack until the 
child thread is completely 
finished. 

Minimizing Message Event 
Initialization: In the OS/2 PM envi¬ 
ronment, a lot of messages are often 
generated within an application. 

In our application, the number of 
messages was not the problem; 
rather, the amount of unnecessary in¬ 
itialization taken to process each 
message needed improvement. For 
example, some parts of the code had 
initialization logic at the beginning 
of the window procedures. Although 
the initialization in question was re¬ 
quired, it was being executed at the 
beginning of a WinProc statement 
before the type of message was de¬ 
termined (and, often, whether or not 
the WinProc should even process the 
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message). An example is shown in 
Figure 5. 

In the preceding case, the initializa¬ 
tion of the variable Pvar is taking 
place before the window procedure 
has determined if Pvar will be used. 
In this example, Pvar should be in¬ 
itialized inside the switch case 
MSG1. Even if Pvar is used in sev¬ 
eral or almost all of the switch’s 
case statements, it should be initial¬ 
ized only when it is needed. 

This type of approach to initializa¬ 
tion in window procedures will in¬ 
crease the size of the code and may 
add to its complexity, but it is defi¬ 
nitely worth the effort for 
performance. 

Other Techniques: Because of the 
requirements for easy maintenance 
and the ongoing development of the 
product, several OS/2 optimization 
methods were not used by the per¬ 
formance team. This does not mean 
that such approaches would not be 
valid for other projects, but simply 
that in some cases the costs out¬ 
weigh the benefits. 

Database Tuning 

Reorganizing: Reorganizing a data¬ 
base is one of the simplest and most 
effective methods of improving data¬ 
base performance. The “Reorg” 
operation physically rearranges the 
rows in each table to optimize 
search time. When performing a 
Reorg it is important to choose the 
most heavily used index as the 
Reorg key. The Reorg can be done 
through the Query Manager interface. 

After reorganizing the database, it is 
necessary to perform the database 
operation “RUNSTATS.” This opera¬ 
tion updates the system tables that 
the OS/2 Database Manager uses to 


MRESULT EXPENTRY WinProcCHWND 
mpl,MPARAM mp2) 

{ 

Pvar - *mpl; 

switch( msg ) 

{ 

Case MSG1: 

<Pvar used here>. 

Case MSG2: 

Default: 

} 

} 


Figure 5. Message Event Initialization 

determine optimum search 
algorithms. 

Also, after the first two steps, the ap¬ 
plication program should be re¬ 
bound to the database. This updates 
the access plans stored in the system 
tables to take advantage of the 
Reorg. 

Database Design: Table design has 
an extremely large impact on per¬ 
formance. An efficient design is the 
best approach to good database 
performance. 

For example, this project had a 
unique situation where a database 
query that required matching of two 
columns was required. This caused a 
performance problem when the data¬ 
base exceeded about 3,OCX) entries. 
Creating an additional table that 
coalesced the two fields into one 
(for search purposes only) seemed to 
be the best solution. This improved 
performance by more than 10 sec¬ 
onds on a large database. 

Indexes: Indexes can also greatly 
improve database performance, but 
there are associated costs. Each addi¬ 


hwnd, USHORT msg,MPARAM 


tional index on a table requires an 
update each time the table is 
changed. Therefore, in many cases, 
an index improves data retrieval, but 
negatively impacts table updates. It 
is important, therefore, to carefully 
consider the use of indexes. Also, if 
an index is used, consider the num¬ 
ber of columns used in the index; 
the more columns, the greater the 
performance impact. 

Database Locking: Database lock¬ 
ing refers to the control of concur¬ 
rent access to the database. Because 
this product did not gain much of a 
performance improvement by chang¬ 
ing locking strategies, this technique 
will not be discussed in detail. For 
more information, refer to the OS/2 
Database Manager Programming 
Guide. 

Conclusion 

The performance team found that 
the most effective techniques for per¬ 
formance improvements were as 
follows: 

• Partial redesign - The refresh 
cache eliminated many calls to 
the server 
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• Memory management 

• Database tuning 

• Structure alignment 

Figure 6 shows the relative effective¬ 
ness of each method used to im¬ 
prove the performance of this 
product. Although this chart can be 
useful to any project, the effective¬ 
ness of each method used will vary 
from project to project. This vari¬ 
ance will depend on the type and 
size of the product. In general, im¬ 
proving the performance of an OS/2 
application depends not on the use 
of a set of techniques, but on the un¬ 
derstanding and effective use of the 
resources being used by the 
application. 
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Creating PM 
Windows with 
Dialog Templates 



Scott Sorensen 
Provo , Utah 

There are advantages to using a 
template structure and the 
WinLoadDlg() function call to de¬ 
fine Presentation Manager (PM) 
windows. This article explains 
how programmers can use this 
method of window creation. 

Most programmers use the 
WinCreateStdWindow( ) and 
WinCreateWindow( ) functions to 
create window panels in their OS/2 
PM programs. There are, however, 
alternative methods. One of these is 
to create dialog templates with the 
dialog box editor. 

Window panels can be created 
efficiently with the dialog box 
editor or defined manually in a 
DLGTEMPLATE or 
WINDOWTEMPLATE structure in 
a resource file and then called with 
the WinLoadDlg() function. This 
method has some advantages over 
creating windows with the 
WinCreateStdWindow( ) and 
WinCreateWindow( ) functions. The 
two most obvious advantages are: 

• The window panels will have the 
same relative dimensions on all 
display monitors, regardless of 
their resolution. 

The dialog box editor allows you 
to design screen panels that will 
have the same relative dimensions 
on all display monitors, regardless 
of their resolution. This is be¬ 
cause the screen panels are saved 
in dialog units, and dialog units 
are defined in terms of the system 
font. One dialog unit is equal to 


one-fourth the width of the aver¬ 
age system font character by one- 
eighth the height of a system font 
character. (Because system font 
characters are approximately one- 
half as wide as they are tall, the 
width and height of a dialog unit 
are also approximately equal.) On 
the other hand, the WinCreateStd- 
Window( ) and WinCreateWin- 
dow() functions define the 
window position and the window 
size in terms of pixels. This re¬ 
quires more complicated coding 
to give screen panels the same ap¬ 
pearance on display monitors with 
different resolutions. 

• Panel creation is faster and easier 
with the dialog box editor. 

The dialog box editor has a 
WYSIWYG display that makes it 
easy to create window panels and 
position control windows. It auto¬ 
matically stores the size and posi¬ 
tion information in your window 


template. This eliminates the need 
to create, size, and position the 
control windows in your program 
code. 

The DLGTEMPLATE or 

WINDOWTEMPLATE 

Structure 

PM defines windows in window tem¬ 
plate structures. The dialog box edi¬ 
tor saves the window panel in a type 
of window template called a 
DLGTEMPLATE. This file has the 
extension .dig. The 
DLGTEMPLATE can then be in¬ 
cluded in the resource file and modi¬ 
fied, if necessary, to add additional 
items that could not be created with 
the dialog box editor. The 
DLGTEMPLATE structure can also 
be created manually and inserted 
directly into the resource file. It is 
important to have a general under¬ 
standing of this structure, regardless 
of which method you use to create 
the DLGTEMPLATE. 
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DLGTEMPLATE ID_MAINBOX LOADONCALL MOVEABLE DISCARDABLE 

BEGIN DIALOG "VM File Transfer", ID_MAINBOX, 21, 38, 336. 181, FS_NOBYTEALIGN | 
FS_DLGBORDER | FS_DLGBORDER | WS_VISIBLE | WS_CLIPSIBLINGS | 
WS_SAVEBITS, FCF_SYSMENU | FCF_TITLEBAR | FCF_MINBUTTON | 

FCF_MAXBUTTON 

BEGIN CONTROL “Help", ID_HelpPB, 160, 10, 27, 13, WC_BUTTON, BS_PUSHBUTTON | 

BS.DEFAULT | WS_TABSTOP | WS_VI SIBLE 
CONTROL ID_StatusMLE, 22, 31, 199, 40. WC_MLE, MLS_BORDER | 

MLS_WORDWRAP | WS_GROUP | WS_TABSTOP | WS_VISIBLE 
CONTROL “Transfer file", ID_TransferGB, 18, 96, 298, 74, WC_STATIC, 


SS_GROUPBOX | WS_GROUP | WSJ/ISIBLE 
CONTROL ID_SessionEF, 131, 145. 21. 8. WC_ENTRYFIELD, ES_LEFT | 

ES_MARGIN | WS_TABSTOP | WS_VISIBLE 
PRESPARAMS PP.BACKGROUNDCOLORINDEX CLR_BLUE 
CONTROL “", ID_SourceEF, 131, 123, 164, 9, WC_ENTRYFIELD, ES_LEFT | 
ES_AUTOSCROLL | ES_MARGIN | WS_TABSTOP | WS_VISIBLE 
PRESPARAMS PP_BACKGROUNDCOLORINDEX CLR_RED 
CONTROL “”, ID_DestinationEF, 130, 104, 165, 8, WC_ENTRYFIELD, 

ES_LEFT | ES_AUTOSCROLL | ES_MARGIN | WS_TABSTOP | WS_VISIBLE 
PRESPARAMS PP..BACKGROUNDCO LORI NDEX CLR_GREEN 


/* Additional CONTROLS... */ 

END 

END 


Figure 1. Dialog Template with Presentation Parameters 


The keywords DLGTEMPLATE and 
WINDOWTEMPLATE are almost 
synonymous and can be inter¬ 
changed in most cases. Every win¬ 
dow in a PM program can be 
defined in a DLGTEMPLATE or 
WINDOWTEMPLATE structure. 
The template starts with a 
WINDOWTEMPLATE or a 
DLGTEMPLATE statement, which 
tells the resource compiler that a 
window definition is to follow. It 
also specifies the resource ID, load 
options, memory options, and code 
page to be associated with that win¬ 
dow. The dialog box editor specifies 
the following options for this 
statement: 

• The resource ID is defined by the 
user in the dialog box editor 

• The load option is 
LOADONCALL 

• The memory options are 
MOVEABLE and 
DISCARDABLE 


These options will not need to be 
changed for most programs. 

The DLGTEMPLATE or 
WINDOWTEMPLATE statement 
is followed by one or more 
CONTROL, WINDOW, or 
DIALOG statements. These state¬ 
ments can be nested. The 
CONTROL and WINDOW state¬ 
ments specify the text associated 
with a title bar or window text, a 
window ID, position, size, and class, 
window styles, and control data. The 
DIALOG statement is the same as 
the CONTROL and WINDOW state¬ 
ments with the exception that no 
window class is specified. With the 
DIALOG statement, the 
WC_FRAME class is implicit. 

The dialog box editor uses the 
CONTROL statement to specify all 
control windows that are children of 
the dialog box. There is also a set of 
predefined control statements that 
can be used to specify certain con¬ 


trol windows such as CTEXT for 
centered static text and 
ENTRYFIELD for an entry field 
control. A control window must be a 
child of either a WINDOW or a 
DIALOG. 

The WINDOW statement or control 
statement can be used to specify 
user-defined windows if the window 
is registered with the 
WinRegisterClass() function before 
the WinLoadDlg( ) function call is 
made. 

The template can also contain presen¬ 
tation parameters that define addi¬ 
tional characteristics of a window. 

To do this, specify the keyword 
PRESPARAMS followed by the 
presentation parameter identifier and 
its value. 

Using the Template 

The example DLGTEMPLATE 
structure (Figure 1) defines a dialog 
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Figure 2. Loading and Displaying a Window 


window that owns several control 
windows. 

The dialog box editor was used to 
create the window panel and posi¬ 
tion the control windows. The struc¬ 
ture was then copied into the 
resource file, and the statements for 
the presentation parameters were 
added. The presentation parameters 
simply change the color of each en¬ 
try field to demonstrate how presen¬ 
tation parameters are set in a 
template structure. The keyword 
PRESPARAMS was used, followed 
by the 

PP_BACKGROUNDCOLORINDEX 
identifier and a value such as 
CLR_RED. In the main() function, 
the WinCreateStdWindow( ) func¬ 
tion call is replaced with the 
WinLoadDlg( ) and 
WinProcessDlg( ) function calls. 
There is no longer any need for mes¬ 
sage queue processing, but a mes¬ 
sage queue must still exist or the 
application will not run. The main( ) 
function is very simple, as shown in 
Figure 2. This skeleton example 
demonstrates how the dialog box edi¬ 
tor can be used to create a main win¬ 
dow that will display the same on all 
display monitors. 


The window will look like Figure 3. 

Adding Icons and Action 
Bars 

An action bar can be added to a dia¬ 
log window, and an icon can be asso¬ 
ciated with a dialog window in the 
WM_INITDLG part of the dialog 
window procedure. 


Once a resource ID has been defined 
in a header file, and the icon has 
been associated with this resource 
ID in the resource file, then the icon 
can be loaded with a call to the 
WinLoadPointer( ) function. This 
call must be followed by sending a 
message to the default dialog proce¬ 
dure with a WM_SETICON 
message. 



Figure 3. Window Defined in Figure 1 and Called in Figure 2 
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case WM^INITDLG: 

hDlgBoxIcon - WinLoadPointer(HWND_DESKTOP, 
NULL, 

ID_DLGB0X); 

WinDefDlgProc(hwnd, WM_SETICON, 

(MPARAM)hDl gBoxIcon, 

(MPARAM)O); 

hMenu = WinLoadMenu(hDlg, NULL, ID_MENU); 

WinSendMsg(hDl g , WM_.UPDATEFRAME, (MPARAM)O, 
(MPARAM)O); 


break; 


Figure 4. Associating an Icon with a Dialog Template Window 


WINDOWTEMPLATE ID_MAINBOX 
BEGIN 

FRAME NULL, 0, 50, 34, 285, 190, WS_VISIBLE, 

FCF_TITLEBAR | FCF_SYSMENU | FCF^SIZEBORDER | FCF_MINMAX | 

FCF_TASKLIST 

BEGIN 

WINDOW "”. ID_CLIENT, 0, 0, 285, 180, WC.MYCLASS, WS_VISIBLE, FCF_TITLEBAR | 
FCF_SYSMENU 

BEGIN 

CONTROL ID_TASKLIST, 166, 9, 134, 78, WC_COMBOBOX, CBS_SIMPLE | 

WS_GR0UP | WS_TABSTOP | WS_VISIBLE 

CONTROL "Remove/Restore Options”, ID_TASKGROUP, 24, 62, 87, 56, WC_STATIC, 
SS_GROUPBOX | WS_GROUP | WS_VISIBLE 

CONTROL “Icon”, ID_TASKICON, 33, 96, 74, 10, WC_BUTT0N, BS_AUTORADIOBUTTON | 

WS_TABSTOP | W S_VISIB L E 

CONTROL “Program”, ID_PROGRAM, 33, 81, 74, 10, WC_BUTT0N, BS-AUTORADIOBUTTON | 
WS_TABSTOP | WS-VISIBLE 

CONTROL “Both”, ID_B0TH, 33, 67, 74, 10. WC_BUTT0N, BS-AUTORADIOBUTTON | 

WS_TABSTOP | WS-VISIBLE 

CONTROL “Program Name”, 65535, 171, 100, 73, 8, WC_STATIC, SS.TEXT | 

DT_LEFT | DT_T0P | WS_GROUP | WS_VISIBLE 

CONTROL "Restore”, ID_REM0VE, 25, 45. 86, 13, WC_BUTTON. BS_PUSHBUTTON | 
WS_TABSTOP | WS-VISIBLE 

CONTROL "Remove”, ID_REM0VE, 25, 32, 86. 13, WC_BUTT0N, BS_PUSHBUTTON | 

WS_TABSTOP | WS-VISIBLE 

CONTROL “Cancel”. ID_CANCEL, 25. 10. 86. 13, WC_BUTT0N, BS_PUSHBUTTON | 

BS_DEFAULT | WS_TABSTOP | WS.VISIBLE 

END 

END 

END 


Figure 5. Window Template with a Frame and Controls 
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Figure 6. Window Defined in Figure 5 and Called in Figure 4 


When an action bar is needed, it can 
be added by putting a menu template 
into the resource file and then mak¬ 
ing a call to the 

WinLoadMenu( ) function. After the 
call to the WinLoadMenu( ) func¬ 
tion, a WM_UPDATEFRAME mes¬ 
sage must be sent to the dialog 
window. The code required to add 
an action bar and an icon is shown 
in Figure 4. 

The last bit of sample code demon¬ 
strates how to use a template to de¬ 
fine a typical window with a frame, 
a client, and some control windows 
(Figure 5). 

It is necessary to register 
WC_MYCLASS with a 
WinRegisterClass() function call be¬ 
fore making the call to 
WinLoadDlg( ). The menu is loaded 
with the WinLoadMenu( ) function 
in the WM JNITDLG case. This 
menu is defined in a menu template 
in the resource file. 

The window will look like Figure 6. 

Improved Usability with 
OS/2 2.0 

This method is not appropriate for 
all applications. Programs with only 
one screen panel and multiple con¬ 
trol windows are particularly well 


suited for this method. (The Presenta¬ 
tion Manager control panel utility is 
a good example of this.) 

The dialog box editor is a powerful 
tool. OS/2 version 2.0 will provide 
even better usability, making win¬ 
dow panel creation easier and faster 
yet. Ease-of-use, along with the de¬ 
vice independence offered by defin¬ 
ing windows in window templates, 
are two of the advantages of using 
this method to create windows. 
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•NET ADMIN WIBM0S2S1 /C NET USERS | rxqueue /FIFO’ 


Figure 1. Example of a Command Where Output Is in the Queue 


REXX Program 
for OS/2 LAN 
Server 

Carolyn Easter 
IBM Corporation 
Austin, Texas 

In OS/2 LAN Server environments, 
an administrator needs the ability 
to create user IDs that have identi¬ 
cal logon resources. The program 
described here does just that. It 
uses REXX, OS/2, and LAN Server 
commands to create a new user 
ID modelled from another created 
user ID. 

REXX is a language included in 
OS/2 Extended Edition 1.30.1 and 
Standard Edition 1.30.1 and is ideal 
for those interested in creating so¬ 
phisticated batch programs. LAN 
Server does not interact directly with 
REXX, but because it has a com¬ 
mand line interface, the REXX pro¬ 
gramming language can be used to 
create useful tools. 

An example of a REXX program fol¬ 
lows this article (Figures 6a through 
6g). The functions provided by this 
REXX program are: 

• Create a user ID modeled after a 
defined user ID 

• View user IDs defined to the 
named domain controller server 

• View specific user ID details 

• Delete a specific user ID 

Data Structures 

This REXX program is interactive, 
relying on users to input information 
to the program. The program re¬ 
quires that the output from some of 
the commands be stored in a conven¬ 
ient place for processing. REXX pro¬ 
vides a dynamic data construct 
called a rxqueue , where output from 


command line commands or pro¬ 
gram data can be stored. Because 
OS/2 LAN Server command output 
is either printed to the screen or redi¬ 
rected to a file or printer, the rx¬ 
queue is an ideal place to store the 
output. 

An example of a command where 
the output of the command is placed 
in the queue is shown in Figure 1. 
The command is enclosed in single 
quotes. Double quotes can also be 
used. The pipe character “I” is used 
in the command string to direct out¬ 
put to program files. The NET 
USERS command returns a list of 
the defined users on the server 
named IBMOS2S1. Now that the 
data is in a REXX queue structure, 
the REXX commands PULL and 
PUSH can be used to remove queue 
elements from the queue (PULL) or 
place elements in the queue (PUSH). 

In this REXX program, a subroutine 
called PULLQUEUE removes the 
queue elements and places them in a 
data structure accessible to all por¬ 
tions of the REXX command file. 

The PULLQUEUE subroutine is 
shown in Figure 2. The first execu¬ 
table statement in the subroutine cop¬ 
ies the number of the queued 
elements into the first variable of LI 
(the zero index). LI is called a stem 
variable and is similar to an array. 
One function not available using 
stem variables that is available when 
using arrays is the arithmetic opera¬ 
tions on the array index. With stem 
variables, the index number (.1) can¬ 
not be incremented, decremented, or 
otherwise manipulated inside the 
stem variable declaration. The opera¬ 


tion 1 = 3*1 can be used, then I used 
as an index (LI.I). 

In the next line, the PULL function 
is used to pull the data from the 
queue into the variable LI.I where .1 
is a value 1 to the number of queue 
elements. By using the PARSE state¬ 
ment with the PULL function, the 
data from the queue is not upper- 
cased, but remains in its original 
state. The PULL function by itself 
will uppercase the entire data string. 

Program Flow 

Figure 3 shows the program flow. 
The program is started by typing in 
the name of the command file. 

There are no parameters. The file is 
named LANUSER2.CMD. 

Before presenting the main menu for 
selection, it is important for the pro¬ 
gram to have two major pieces of 
information: 

1. What is the name of the domain 
controller? When creating user IDs, 
the domain controller must be the 
server updated with the new user 
names because this server replicates 
the user names and group names to 
the other servers in the domain. The 
server name is validated as a domain 
controller using the NET VIEW 


PULLQUEUE: 

LI.O - queuecK); 

DO I - 1 TO LI.0 
PARSE PULL LI.I 

END 

RETURN 


Figure 2. PULLQUEUE Subroutine 
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command and NET ACCOUNTS 
command. 

2. Where is the administrator 
logged on? This is important when 
issuing LAN Server commands to 
the domain controller, because the 
NET ADMIN command must pre¬ 
cede each command. It is also impor¬ 
tant for other OS/2 commands that 
may or may not support redirected 
or UNC file requests. 

Validation of Server Name 

One of the first actions done by the 
program is to prompt the administra¬ 
tor for the name of the server. 
Granted, that if a utility like this pro¬ 
gram were going to be used on only 
one domain, the name of the server 
could be hard coded onto the vari¬ 
able name SERVER. For flexibility, 
the program was written to be used 
in any domain. 

The NET VIEW command is used 
to list the server names available 
and to validate that the name of the 
server machine entered is one of the 
machines in this list. It is possible to 
administrate another domain while 
logged on to the default domain. 

This requires that the administrator 
has added the domain name to the 
IBMLAN.INI file, 
othdomains=xxxxxxxx, of the re¬ 
quester being used as the administra¬ 
tor’s workstation and that the 
administrator’s user ID and pass¬ 
word are known to the other do¬ 
main. When the NET VIEW 
command lists the server names 
available, the other domain’s servers 
will also be listed, and validation of 
the server name will succeed. 

After the server name is validated, 
the server account information is 
checked using the NET 
ACCOUNTS command to ensure 
that it is a domain controller. If the 


Start 


1 



Figure 3. Initialization and Main Panel Program Flow 


role is PRIMARY, the server is a do¬ 
main controller and the program can 
continue. Otherwise, the program is¬ 
sues an error message and exits. 

Location Checking for 
Administrator 

The only additional information 
needed before proceeding to the 
main menu is determining the loca¬ 
tion of the administrator executing 
this program. If the administrator is 
running the program at the domain 
controller, then the NET ADMIN 
prefix is not needed for the OS/2 
LAN Server commands. If the user 
is remote, the NET ADMIN prefix 
must be issued in front of the com¬ 
mands. A variable LANFRONT is 
set up to reflect this situation. If 
LANFRONT is null, the administra¬ 


tor is at the domain controller; other¬ 
wise, LANFRONT is the value 
’NET ADMIN Wservername /c’. Dur¬ 
ing the executable phase of the pro¬ 
gram, this variable is tested for NUL 
to indicate the location of the 
administrator. 

The NET ACCOUNTS command is 
issued to determine if the administra¬ 
tor is located locally or remotely. If 
the role of the local workstation is 
PRIMARY, the administrator is at 
the domain controller. Otherwise, 
the administrator is remote. 

Create User 

The program has several functions. 
All except the create user are trivial. 
The program flow for this function 
is shown in Figure 4. 
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This discussion focuses on the 
model user function and how it is ac¬ 
complished using the NET USER 
command and knowledge of the di¬ 
rectory structure of the domain con¬ 
trol database. 

The administrator selects “Create 
new user” from the menu and the 
program prompts for the user name 
to use as a model. This user ID is 
checked against a created list of us¬ 
ers to make sure it exists in the do¬ 
main. The program then prompts for 
the user name to create and is 
checked to make sure the ID does 
not exist. The program then loops 
each time a user is created and asks 
for another user ID to create. This al¬ 
lows many user IDs to be created 
from the model user. Each new user 
ID can be created as either an admin¬ 
istrator or user, can have a unique 
password, and can have a unique 
comment string. These parameters 
are then used on the NET USER 
command. 

After the user specifications are de¬ 
termined, the cloning of the model 
user ID environment takes place. 

This is accomplished by duplicating 
the user directory of the new model 
user ID. The user environment files 
are contained in the 
\IBMLAN\DCDB 
\USERS\username where username 
is the name of the user. The list of 
files that might be present in this 
subdirectory are shown in Figure 5. 
All files in the subdirectories are 
copied to the new user’s newly cre¬ 
ated subdirectory. 

The program uses the MD command 
to create these subdirectories, using 
the variable ROOT to specify the 
path. The program uses the fact that 
an automatic share occurs at each 
server and is named 
\\servemame\IBMLAN$. Therefore, 
the value of ROOT is 


1 Selected 


1 



Figure 4. Program Flow for Create User Function 
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\\servemame\IBMLAN$. This share 
name is one of several that occur 
when the SERVER service starts. 

All drives are shared as 
\\servemame\d$ where d is the drive 
letter. 

The next task is copying the files 
from the model ID subdirectory to 
the new user ID subdirectory. NET 
COPY is used because this com¬ 
mand supports local and remote 
COPY commands. 

The user is then added to the group 
IDs to which the model user has 
membership. 

If the model user has a home direc¬ 
tory, the program determines where 
the new user’s home directory will 
be by following these guidelines: 

1. If the model user’s home direc¬ 
tory name ends with the model 


user’s name, another like subdirec¬ 
tory is created using the new user’s 
name as the subdirectory name. 

2. Otherwise, the same subdirectory 
is used as the new user’s home 
directory. 

Home directories no longer have an 
ALIAS, but if desired, the adminis¬ 
trator can create one. 

The program returns for the user to 
enter another user ID to be created, 
using the same model user ID name 
entered for the previous user ID. 

Other Functions 

Several other functions are available: 

• View valid users for the domain 

• View a user ID profile 

• Delete a user 


LIST.A - DOS Private Applications 
LIST.S - Served Applications panel entries 
LIST.U - Logon Assignments for DOS 
USER.A - OS/2 Private Applications 
USER.L - Logon Assignments for OS/2 

USER.S - Desktop Manager, Public Applications window entries 

EXTERNAL.OFF - present if user has ever attached to an external resource 

EXTERNAL.ON - present if user detaches from an external resource or logs 
off when attached to an external resource 

PROFILE.CMD - a file run when logon occurs on an OS/2 machine (not 
mandatory) 

PROFILE.BAT - a file run when logon occurs on a DOS machine (not 
mandatory) 


Figure 5. List of Files in \IBMLAN\DCDB\USERS Subdirectory 


The delete user process removes the 
user ID, the user definition subdirec¬ 
tory on the domain controller, and 
associated access control profiles. 

The User Profile Management delete 
user function does not delete the ac¬ 
cess control profile for the user defi¬ 
nition subdirectory, only the 
permissions and leaves an empty ac¬ 
cess control profile in the NET.ACC 
file. 

Summary 

The REXX programming language 
is flexible and can be used to create 
effective tools for administrating an 
OS/2 LAN Server domain. Imagine 
what could be done with the error 
logs, message logs, and audit trails 
provided with the LAN Server. Each 
of these logs gives valuable informa¬ 
tion to the administrator and can be 
used in an integrated way to provide 
better problem determination, statisti¬ 
cal reporting, and general 
administration. Food for thought: 
this information could be formatted 
by a REXX program and imported 
to Database Manager. 
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/*★*★★*★★★*★★*★*★★*★**★*★**★★★★**★*★★★★*★*★★★★★*★*★★*★★*★★**★★**★★★***★**★★*★/ 


/* 5748-XX8 (C) COPYRIGHT IBM CORP. 1990 */ 
/* ALL RIGHTS RESERVED */ 
/* LICENSED MATERIALS-PROPERTY OF IBM */ 
/* SEE COPYRIGHT INSTRUCTIONS, G120-2083 */ 

/*LANUSER2.CMD */ 
/* REXX exec for creating user IDs on LAN Server 1.30.1 domains */ 
/* Assumptions: User is logged on as an administrator */ 
/* VERSION 2.0 */ 
/* This version supports the enhanced architecture and */ 
/* command line support for the home directory. Messages */ 
/* have been separated for ease of translation. */ 


/* initialize */ 

MODEL-’’ 

ROOT-'’ 

R- ’ * 

SERVER-’’ 

NAME-’’ 

/* MESSAGES BLOCK - TRANSLATE THESE BLOCKS OF TEXT TO OTHER LANGUAGES */ 
GREET.0 - 8 
GREET.1 -’ 

GREET.2 - ” 

GREET.3 
GREET.4 -’ 

GREET.5 -’ 

GREET.6 =’ 

GREET.7 =’ 

GREET.8 - 
CREATE.0 - 5 
CREATE.1 - 
CREATE.2 = ’ 

CREATE.3 = ’ 

CREATE.4 = ’ 

CREATE.5 = ’ 

THANKS =’ Thank you!* 

A = ’A’ 

US - 'U' 

QUEST.1 -'ENTER THE NAME OF THE USER TO DELETE’ 

QUEST.2 -'ENTER THE NAME OF THE USER’ 

QUEST.3 -'ENTER THE MODEL NAME. ' 

QUEST.4 -'ENTER THE USER NAME. ’ 

QUEST.5 -’DO YOU WANT TO RETURN TO THE MENU (Y/N)?.' 

QUEST.6 -'DELETE ? (Y/N)’ 

QUEST.7 -'TYPE IN THE USER COMMENT’; 

QUEST.8 -’IF THE USER IS TO HAVE A PASSWORD, ENTER THE PASSWORD’; 

QUEST.10 -’IS THE USER ADMIN OR USER? (A/U) ’ ; 

QUEST.11 -’WHAT IS THE NAME OF THE SERVER WHICH IS THE DOMAIN CONTROLLER?' 

YES - 'Y' 

NO = ’N’ 

INFOl = 'THESE ARE THE VALID SERVER NAMES:’ 

INF02 = ’PROGRAM WILL EXIT.’ 

INF03 = 'Name being used as a model is: ' 

INF04 - ' DELETING USER. ’ 

INF05 - ’ CREATING USER. ’ 

INF06 - ’Last name used was: * 

INF07 - “Wait 30 seconds if users home directory is on an additional server.' 
ERR0R1 -’THE SERVER NAME YOU ENTERED IS NOT THE DOMAIN CONTROLLER’ 

ERR0R2 -'THE SERVER NAME IS NOT VALID’ 

ERR0R3 -’ENTER A VALID CHOICE, PLEASE’ 

ERR0R5 -’USER DOES NOT EXIST. RE-ENTER NAME PLEASE.’ 

ERR0R6 - ’USER ALREADY EXISTS. RE-ENTER NEW USER NAME' 


This module will allow you, the administrator, to: ’ 

Create user IDs on a domain controller and model the' 
new user on a previously created user.' 

See what users IDs are valid for the domain.' 

See information about a specific user ' 

Delete a user’ 


This routine will create a user modeled after another user.’ 

This means all logon assignments and user attributes are copied’ 
to the new user as well as creating a home directory if the ’ 
model user has a home directory. 


Figure 6a. Source Listing for LANUSER2.CMD 
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MENU.0 - 7 

MENU.1-' SELECT THE FUNCTION YOU WISH TO PERFORM * 

MENU.2*'’ 

MENU.3=' 1. CREATE USER(S) USING A MODEL’ 

MENU.4-’ 2. SEE WHAT USERS ARE DEFINED’ 

MENU.5-’ 3. SEE INFORMATION ABOUT A SPECIFIC USER’ 

MENU.6=’ 4. DELETE A USER’ 

MENU.7=’ 5. EXIT THIS UTILITY' 

/* BEGIN */ 

’@ECHO OFF’ 

' CLS'; 

DO I - 1 TO GREET.0 

SAY GREET.I 

END 

’PAUSE’; 

SAY 

SAY QUEST.11 
SAY 

PARSE UPPER PULL SERVER; 

SERVER-STRIP(SERVER); 

SAY THANKS 

/★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★*★★★★★★★**★★★★★★★★*/ 
/* VALIDATE SERVER NAME */ 

/★★★★★★★★★★★★★★★★★★★★★*★*★*★★★*★★★******★★*★★★*★***★★★★*★★*★★★★★★*★★★★★★★★*★★/ 
’ NET VIEW | rxqueue /FIFO' 

CALL PULLQUEUE; 

DO I - 1 TO LI.0 

PARSE VAR LI.I ’\\’ SERV COMMENT . 

IF SERV=SERVER THEN LEAVE 
END 

IF SERV SERVER THEN DO 
SAY ERROR2 
SAY INFOl 
’ NET VIEW ’; 

’PAUSE’; 

EXIT 

END 

ELSE DO 

'NET ADMIN W'SERVER' /c NET ACCOUNTS | rxqueue /FIFO’; 

CALL PULLQUEUE; 

PARSE VAR LI.6 FUNCTION ’:’ ROLE . 

ROLE - STRIP(ROLE); 

IF ROLE ’PRIMARY’ THEN DO 
SAY ERROR1 
SAY INF02 
EXIT; 

END 

END 

/★FIND OUT IF USER IS USING DOMAIN CONTROLLER */ 

LANFRONT-’NET ADMIN W'SERVER' /c'; 

ADMINQ-'V” 

ROOT-’ W’SERVER’XIBM LANS’ ; 

’ NET ACCOUNTS | rxqueue /FIFO’ 

CALL PULLQUEUE; 

PARSE VAR LI.6 FUNCTION ROLE . 

ROLE - STRIP(ROLE); 

IF ROLE = ’PRIMARY’ THEN DO /* USER IS AT DOMAIN CONTROLLER */ 

LANFRONT-” 

ADMINQ-’"* 

END 

/* DETERMINE DRIVE LETTER OF DOMAIN CONTROLLER */ 

LANFRONT 'NET SHARE IBMLANS | rxqueue /FIFO’ 

CALL PULLQUEUE 


Figure 6b. Source Listing for LANUSER2.CMD 
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PARSE VAR LI.2 P PATH . 

PATH-STRIP(PATH) 

PARSE VAR PATH DO *:\’ IBM 

/★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★it*******************************/ 

/*SET UP A LIST OF USERS TO USE IN VALIDATION ****** *********/ 

CALL SETUPUSERS; 

/* BRING UP THE MAIN MENU */ 

/★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★it*************** / 

DO FOREVER 
* CLS *; 

DO I - 1 TO MENU. 0 
SAY MENU.I 

END 

KEY-'* 

DO WHILE KEY-” 

PARSE PULL KEY; 

END 

SELECT 


WHEN 

KEY-1 

THEN 

CALL 

CREATEM 

WHEN 

KEY-2 

THEN 

CALL 

DUSERS 

WHEN 

KEY-3 

THEN 

CALL 

USERINFO 

WHEN 

KEY-4 

THEN 

CALL 

DELETE 

WHEN 

KEY-5 

THEN 

EXIT 


OTHERWISE 

DO /* 

need 

a valid selection */ 


rxqueue /FIFO’ 


NAMES.1 NAMES.2 NAMES.3 
STRIP(NAMES.1) 


SAY ERR0R3 
’PAUSE’; 

END 

END 

END 

/★★★★★★SUBROUTINES ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★**★★★★★★★★★★★★★★★★★★★★★★★★★★/ 
/★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★/ 
/* CREATE LIST OF USERS */ 

/★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★/ 
SETUPUSERS: 

LANFRONT ’ NET USERS 
CALL PULLQUEUE 
USERS.0 = 0 
C - 1 

DO I - 3 TO LI.O 
PARSE VAR LI. I 
NAMES.1 
NAMES.2 - STRIPCNAMES.2) 

NAMES.3 - STRIP(NAMES.3) 

IF NAMES.1 ’THE’ THEN DO 
DO U - 1 TO 3 

IF NAMES.U ” THEN DO 
USERS.C - NAMES.U 
C - C + 1 

USERS.0 - USERS.0 + 1 
END /*IF*/ 

END /*DO*/ 

END /*IF */ 

END /*DO */ 

RETURN; 

/★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★/ 
/* LOOK AT INFORMATION ABOUT A SPECIFIC USER */ 

/★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★/ 
USERINFO: 

SAY 

SAY QUEST.2; PARSE UPPER PULL INFO; 

LANFRONT 'NET USER’ INFO ’ I MORE’; 


Figure 6e. Source Listing for LANUSER2.CMD 
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'PAUSE *; 

RETURN 

/ic*ic-kicicic*icicicic*icif*1ric*****ie*1c**i'ic*****-k-k-k-k-k-k-k'k-k-k-k-k-k-k'k-k'k'k-k-kJt-k-k-k-k'k'k-k'k-k'k'k'k-k-kic-k'k-k-k-ie/ 

/* LOOK AT CREATED USERS */ 

/****************************************************************************/ 
DUSERS: 

LANFRONT * NET USERS'; 

’PAUSE*; 

RETURN 

/★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★I*** j 

/* DELETE A USER */ 

/★★★★★*★★*★*******★*★*★*★★*★★★★★★★★*★★**★★★★★★★★*★*★*★★*★★★*★*★★**★★★*★★★★★★* j 

DELETE: 

DO FOREVER 

R-GETUSER(1,1); 

IF R-0 THEN DO 
SAY QUEST.6 
PARSE UPPER PULL ANS; 

IF ANS = YES THEN DO 
SAY INF04; 

LANFRONT * NET ACCESS ’DD*:\IBMLAN\DCDB\USERS\* NAME' /D* 

LANFRONT ' NET ACCESS *DD*:\IBMLAN\DCDB\USERS\’NAME*\BATCH /D’ 
LANFRONT * NET USER * NAME * /D* 

RET=MLIST(NAME.O) 

END 

END 

ELSE LEAVE 
END /*DOFOREVER*/ 

RETURN 

/* CREATE A USER - MODELS AFTER ALREADY CREATED USER */ 

/★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★*★★★★★*★★*★★★★★*★★★■*•/ 
CREATEM: 

' CLS *; 

DO I = 1 TO CREATE.0 
SAY CREATE.I 
END 

'PAUSE*; 

' CLS'; 

R-GETUSER(3,1); 

MODEL-NAME 
NAME - " 

IF R-0 THEN DO 

LANFRONT 'NET USER 'MODEL' | rxqueue /FIFO ' 

CALL PULLQUEUE; 

GROUP. - 
GROUP.0 = 0 
GR = 0 

LI.O - LI.O - 1 

PARSE VAR LI.27 GP MEMB LI.27 

DO I = 27 TO LI.O 

PARSE VAR LI.I G.l G.2 . 

DO J = 1 TO 2 

G.J - STRIP(G.J,,'*') 

IF G.J " THEN DO 
GR - GR + 1 
GROUP.GR - G.J 
END 
END 
END 

GROUP.0 - GR 

DO FOREVER /* GET USER INFORMATION */ 

'CLS'; 


Figure 6d. Source Listing for LANUSER2.CMD 
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SAY INF03 MODEL 
SAY INF06 NAME 
R-GETUSER(4,0); 

IF R = 0 THEN DO 
AU- 0 

DO WHILE AU-0 /* GET USER TYPE */ 

SAY QUEST.10;PARSE UPPER PULL AU; 
IF AU A & AU US THEN AU-0 


END 

PASSWORD-’' 

SAY QUEST.8; /**GET PASSWORD */ 

PARSE UPPER PULL PASSWORD 
COMMENT =”; 

SAY QUEST.7; /**GET COMMENT */ 

PARSE PULL COMMENT 
SAY INF05 
IF AU-A THEN DO 
AU-’ADMIN'; 

END 
ELSE DO 

AU-'USER' ; 

END 

IF PASSWORD-” THEN DO 
PASSREQ-* NO'; 

END 
ELSE DO 

PASSREQ-’YES’; 

END 

LANFRONT ’ NET USER ’ NAME PASSWORD ' /ADD /PRIV:’AU ’/PASSWORDREQ:'PASSREQ ' 

/USERCOMMENT:*ADMINQ||COMMENT||ADMINQ; /* THIS LINE CONTINUED FROM PREVIOUS, ENTER AS ONE */ 
R-MLIST(NAME,1) 

'MD ’ ROOT’\DCDB\USERS\*NAME; 

’MD ’ ROOT*\DCDB\USERS\’NAME'\BATCH’; 

DIRY - DD’:\IBMLAN\DCDB\USERS\' NAME; 

R-ACCESSPROCSERVER,DIRY); 

IF R-l THEN DO 

LANFRONT ’ NET ACCESS ’DD’:\IBMLAN\DCDB\USERS\’NAME ’/GRANT ’ NAME *:RWCXDAP’ 
LANFRONT ' NET ACCESS ’DD’:\IBMLAN\DCDB\USERS\’NAME'\BATCH /GRANT ’ NAMERWCXDAP ’ ; 


END 

ELSE DO 

LANFRONT ' NET ACCESS ’DD’:\IBMLAN\DCDB\USERS\’NAME ’/ADD ’ NAME’:RWCXDAP’ 
LANFRONT ' NET ACCESS ’DD’:\IBMLAN\DCDB\USERS\'NAME’\BATCH /ADD ’ NAME’:RWCXDAP’; 
END 

’ NET COPY ’ ROOT’\DCDB\USERS\'MODEL' ’ ROOT'\DCDB\USERS\'NAME; 

’ NET COPY ’ ROOT*\DCDB\USERS\’MODEL'\BATCH' ROOT'\DCDB\USERS\’NAME'\BATCH’; 

DO I - 1 TO GROUP.0 

IF GROUP.I = 'USERS’ THEN ITERATE 
IF GROUP.I = 'ADMINS' THEN ITERATE 
LANFRONT 'NET GROUP 'GROUP.I NAME ' /ADD ' 


END 

R= GETHOME(MODEL) /* find out if user has home directory */ 

IF R - 1 THEN DO /* MODEL USER HAS HOME DIRECTORY */ 

PARSE VAR HNAME N.l *\* N.2 *\* N.3 '\* N.4 *\' N.5 *\* N.6 '\* N.7 *\’ N.8 

DIRH-’' 

DO I = 1 TO 8 

IF N.l = "*' THEN LEAVE 
IF MODEL = N.l THEN LEAVE 
DIRH = DIRH'X’N.I 
END 

PARSE VAR DR DR '$' 

IF MODEL- N.l THEN DO 
DIRH - DIRH'\'NAME 


Figure 6e. Source Listing for LANUSER2.CMD 
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’MD \\ ’SERV’\’DR’$’DIRH 
END 

SAY INF07 
’PAUSE’ 

DIRY - DR’ : ’ DI RH 
R=ACCESSPRO(SERV,DIRY); 

IF R-l THEN 'NET ADMIN W’SERV ’ /c NET ACCESS 'DIRY NAME’:XRWCDAP /GRANT’ 
ELSE ’NET ADMIN \\ 'SERV ’ /c NET ACCESS 'DIRY NAME’;XRWCDAP /A’ 

HDIR - HDIR||DIRH 

LANFRONT ’ NET USER ’ NAME ’ /HOMEDIR:’HDIR 


END 

ELSE LEAVE 

END /*DO FOREVER */ 

END 

RETURN; 

/* GET USER NAME ENTERED BY ADMINISTRATOR */ 


*•*****★★★*★★**★*★***★ j 


GETUSER: 

ARG PROMPT,S 
FLAG - 0 

DO WHILE FLAG - 0 
SAY QUEST.PROMPT 
PARSE UPPER PULL NAME; 

L=1ength(NAME); 

IF L=0 THEN DO 
SAY QUEST.5 
PARSE UPPER PULL ANS; 
IF ANS-YES THEN DO 
FLAG-1; 

RU-1 


END; 


ELSE NOP 


END 

ELSE DO; 

RET - USEREXIST(NAME) 

IF RET= 0 & S - 1 THEN DO 
SAY ERROR5 
’PAUSE’ 

END 

ELSE DO 

IF RET - 1 & S - 0 THEN DO 
SAY ERROR6 
'PAUSE * 

END 

ELSE DO 

FLAG - 1 
RU - 0 


END 

END 

END 

END /*DO WHILE */ 

RETURN RU 

/★★★★★★★★★*★★★★★★*★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 

/* CHECK EXISTENCE OF A DEFINED USER */ 

USEREXIST: 

ARG U 
RES-0 

DO I - 1 TO USERS.0 

IF U - USERS.I THEN DO 
RES-1 
LEAVE 


Figure 6f. Source Listing for LANUSER2.CMD 
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END 

END 

RETURN RES; 

/****************************************************************************/ 
/* ADD OR DELETE USER FROM CREATED LIST OF USERS */ 

/****************************************************************************/ 
MUST: 

ARG U,ACT 

IF ACT = 0 THEN DO 

DO I - 1 TO USERS.0 

IF U = USERS.I THEN DO 
USERS.I = “'' 

LEAVE 

END 

END 

END 

ELSE DO 

USERS.0 - USERS.0 + 1 

URS-USERS.O 

USERS.URS = U 

END 

RETURN 0; 

/***+*****************ie'k-k-k-k-k-k-k-k-k'k-k-k'k'k-k-k-k-k-k-kic-k-k-k'k-k-kic-k*-k*ir-k-k-k'k-k'k-k'k-k-k'k-k-k-k-k-k’k-k*-k-k/ 

/* CHECK EXISTENCE OF AN ACCESS CONTROL PROFILE */ 

/****************************************************************************/ 
ACCESSPRO: 

ARG S.DIR 

'NET ADMIN W'S' /C NET ACCESS 'DIR' | rxqueue /FIFO' 

CALL PULLQUEUE; 

RES-0 

PARSE VAR LI.l NETMSG ':' 

IF NETMSG ’NET2222 ’ THEN RES-1 
RETURN RES; 

/★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★■A-* j 

/* GET HOME DIRECTORY INFORMATION */ 

/★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★*★★★★★★★★*★★★★★★★★★★★★★★★★★★★★★★★★★★★/ 
GETHOME: 

ARG NAMMOD 

LANFRONT 'NET USER 'NAMMOD' | rxqueue /FIFO ' 

CALL PULLQUEUE; 

PARSE VAR LI.22 HO DI HDR '\' SERV '\' DR '\' HNAME . 

HDIR-HDR’\'SERV'\* DR 
IF HDR - " THEN DO 

PARSE VAR LI.22 HO DI '\\' SERV '\' DR 'V HNAME . 

HDIR-’\\'SERV'\'DR 

END 

HDIR - STRIP(HDIR) 

IF SERV - " THEN RES- 0 
ELSE RES = 1 
RETURN RES 

f*************ic****ir*ir + * + + + + **ieiric*ic* + ***1c-k’k'k-k-k-k-k-k-k'k-kir-k-k-k-k-k-k-k'k-k-kic-k-k-k'k-k-ie-k-k'k-k-k-k-k/ 

/* PULL QUEUE ROUTINE */ 

PULLQUEUE: 

LI.O - queuedO; 

DO I = 1 TO LI.0 

PARSE PULL LI.I 
END 
RETURN 


Figure 6g. Source Listing for LANUSKR2.CMD 
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Micro Focus 
COBOL/2 and 
the DOS 
Database 
Requester 

Andrew Morbitzer 
Dallas , Texas 

Although IBM OS/2 EE Database 
Manager only supports IBM 
COBOL/2™, today it is not rare to 
find that a combination of different 
vendor packages and languages 
is used. The use of Micro Focus 
COBOL/2 is demonstrated here 
using a sample program. 

Many customers are finding the 
DOS Database Requester a desirable 
step in the evolution from DOS to 
OS/2 systems. Some are choosing 


Micro Focus COBOL/2 to imple¬ 
ment DOS Database Requester appli¬ 
cations. Because Micro Focus does 
not develop the OS/2 Database Man¬ 
ager, some programmers may won¬ 
der if there are reasons not to use 
Micro Focus COBOL/2 to develop 
applications. The following demon¬ 
stration should alleviate insecurities 
about using Micro Focus COBOL/2 
to produce DOS Database Requester 
applications to run against a data¬ 
base server running IBM OS/2 EE 
1.3 and Database Manager. 

The program in Figures la and lb 
was developed to illustrate the use 
of Micro Focus COBOL/2. It runs 
on a DOS Database Requester and 
catalogs the SAMPLE database, 
which is included with IBM OS/2 
EE 1.3 and exists on a database serv¬ 
er. The environment for this applica¬ 
tion is: 


• A PS/2 Model 80-A31 running 
IBM OS/2 EE 1.3 

• A PS/2 P70 running DOS 4.01 
and IBM Local Area Network 
Support Program 1.2 

• An 8228, which provides the to¬ 
ken ring connection between the 
server and requester 

Note: The environment is best set up 
and understood with the help of the 
article “Installing and Using the 
DOS Database Requester” in Issue 
2, 1991, of IBM Personal Systems 
Technical Solutions , G325-5011. 

The procedure described here would 
follow the steps in that article. 

The DOS machine used to run the 
program had Micro Focus COBOL/2 
with updates to version 2.4.37. 
(When installing Micro Focus 
COBOL/2, choose to install for 
DOS only.) Also installed on the 



Now I moan if} ~-~- 

put some clothes on and act like 
adult's, or your federation —- 
membership b history! J 
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DOS machine were the IBM C/2 li¬ 
braries. No fixes were applied to the 
libraries, and they were set up for 
real mode. Installing the IBM C/2 li¬ 
braries is required to give your pro¬ 
gram access to LLIBCA.LIB during 
the LINK step. The machine used 
for compiling these programs had 
Micro Focus COBOL/2 installed in 
the C:\ COBOL directory. The fol¬ 
lowing files were copied into this 
directory: 

• LLIBCA.LIB 

• PCDRSTAT.LIB 

• SQLCA_.CBL. 

The SQLCA_.CBL and 
PCDRSTAT.LIB files are located in 
the \DBDRQLIB. The 
SQLCA_.CBL file is the only .CBL 
file needed for the program in Fig¬ 
ure 1, however, other .CBL files 
from the \DBDRQLIB directory 
may be needed for your Micro Fo¬ 
cus COBOL/2 programs. One such 
file is the SQLDA_.CBL file used to 
process dynamic SQL statements. 
These files must be copied into the 
C:\COBOL directory to ensure that 
the compile and link steps have ac¬ 
cess to the proper external files. If 
you do not copy the external files 
into the directory where the compil¬ 
ing will be done, you must ensure 
that the environment gives access to 
these files. Adding the directories 
where the external files are located 
to the ’ PATH = ’ statement in the 
AUTOEXEC .BAT file on the DOS 
Database Requester will give the re¬ 
quired access. This alleviates the 
need to copy all the required files 
into one directory. 

Once the machines have been prop¬ 
erly configured, the following steps 
are required to actually get the pro¬ 
gram running. 

The first step to creating a success¬ 
ful DOS Database Requester pro¬ 


gram is ensuring that the database 
calls and parameters the programmer 
wants to use are supported by DOS 
Database Requester. A few calls that 
run on an OS/2 database requester 
will either not be available to a DOS 
Database Requester, or need to be 
modified to run properly on a DOS 
machine. The program in Figure 1, 
which catalogs a database, is an ex¬ 
ample of this. 



After the program has 
been written, the second 
step is precompiling it 
with the SQLPREP 
instruction. 


On an OS/2 database requester, one 
of the parameters for the catalog 
function call lists whether the data¬ 
base is local or remote. If local is in¬ 
dicated, another parameter lists the 
drive on which the local database ex¬ 
ists. The same call for DOS Data¬ 
base Requester ignores the local or 
remote parameter, because DOS ma¬ 
chines cannot have local databases, 
and the call uses the drive parameter 
to list whether adapter 0 or adapter 1 
is to be used for the communications. 

After the program has been written, 
the second step is precompiling it 
with the SQLPREP instruction. The 
program must end with \SQB\ The 
.SQB signals the precompiler that a 
COBOL program needs to be pre¬ 
compiled. The precompiling of the 
catalog program for this article used 
the IBM precompiler included with 
IBM OS/2 EE 1.3. The Micro Focus 
precompiler was not tested. 


The SQLPREP does many things for 
the program. SQL inside the pro¬ 
gram is replaced with COBOL func¬ 
tion calls to be used by the COBOL 
compiler. SQLPREPing the program 
can also allow the OS/2 Database 
Manager optimizer to build an ac¬ 
cess plan to the data according to 
the current statistics that Database 
Manager holds about the database. 
During SQLPREP, you have the op¬ 
tion to defer binding, which means 
that your program will not build an 
access plan to the data in the data¬ 
base. Deferring the bind step means 
that you must go back and perform 
an SQLBIND later, but before run¬ 
ning the program. 

Many programmers and program¬ 
ming shops choose to defer binding 
to ensure the access plan for their 
program is up to date. Care should 
be taken that first-time programmers 
of OS/2 database requester applica¬ 
tions be sure to bind their execu¬ 
tables if they have previously chosen 
to defer binding. Whether binding is 
deferred or not, the output of the 
SQLPREP is a .CBL file that will be 
used when compiling. 

The third step is compiling the appli¬ 
cation. Two versions of each copy 
file are needed to compile a COBOL 
database requester application. One 
version includes no underscore, such 
as SQLCA.CBL, and is intended for 
use on OS/2 applications. The other 
version includes an underscore, such 
as SQLCA_.CBL, and is intended 
for use on a DOS application. Ex¬ 
amination of the SQLDA_.CBL and 
SQLDA.CBL files included with 
OS/2 EE 1.3 shows that these are 
identical files. SQLCA.CBL and 
SQL CA_.CBL are also identical for 
the 1.3 release. The other .CBL files 
are different for DOS; OS/2 will not 
work as intended all of the time if 
the incorrect version is used. The 
programmer should inspect the .CBL 
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files in the \SQLLIB directory for 
differences before assuming that the 
files required for DOS Database Re¬ 
quester applications will work on 
OS/2 Database Requesters. 

Performing the precompile, compile, 
and link steps on an OS/2 machine 
for testing may make program devel¬ 
opment simpler by removing some 
obstacles that may be present when 
moving back and forth between 
DOS and OS/2. Precompiling and 
binding can be done only on an 
OS/2 machine. Compiling the appli¬ 
cation for introduction into the pro¬ 
duction environment is best done on 
the DOS machine after Micro Focus 
COBOL/2 has been installed accord¬ 
ing to the instructions in the begin¬ 
ning of this article. 

No special compile options were 
used for the test programs run for 
this demonstration. The testing done 
found that including many compiler 
directives can cause problems that 
are not easily traceable. A good rec¬ 
ommendation is to begin with a sim¬ 
ple program before adding complex 
procedures and directives. No 
changes should be made to the 
COBOL.DIR file after installation 
until a DOS database requester pro¬ 
gram is running with the default 
COBOL.DIR. 

Once compiling is complete, link the 
program. You can use either the Mi¬ 
cro Focus LINKer or the IBM OS/2 
LINKer. The IBM LINKer should 
be used if you intend to use the IBM 
support path. The only link library 
specified is the PCDRSTAT.LIB. If 
you choose, you can explicitly 
specify the PCDRSTAT.LIB, 
LCOBOL.LIB, and LLIBCA.LIB 
when asked for libraries on the 
LINK step; however, the LINKer 
will automatically make use of the 
LCOBOL.LIB and the LLIBC 


A.LIB. No other special link options 
were used for the program in Figure 
1. Again, use only the basic libraries 
and wait until a simple application is 
running before adding more libraries. 



Compiling the application 
for introduction into the 
production environment is 
best done on the DOS 
machine after Micro 
Focus COBOL/2 has 
been installed. 


Before running the programs, you 
must issue SQLLOGON from the 
DOS Database Requester command 
prompt. This is so that when the 
’start using database’ is issued from 
your program, the database server 
can verify that the user has access to 
the database. The SQLLOGON.EXE 
is one of the files that is copied onto 
the DOS Database Requester from 
the \DBDRQLIB directory on the da¬ 
tabase server. Once the program is 
precompiled (SQLPREP), compiled, 
and linked, you can begin trying to 
run it. To look for the errors in the 
COBOL/2 DOS Database Requester 
programs, make generous use of dis¬ 
play statements and the SQLCODE. 
(A few examples of error handling 
in COBOL programs can be refer¬ 
enced in the IBM OS/2 Extended Edi¬ 
tion Database Manager Version 1.3 
Programming Guide and Reference , 
Volume 2 (S01F-0292) in the sec¬ 
tion on programming with 
COBOL/2.) 

A concern when compiling Micro 
Focus COBOL/2 is the size of the 


executable module. Care must be 
taken to ensure that this module can 
be loaded and run in the memory 
left after any device drivers and 
IBM DOS have been loaded. Micro 
Focus has a memory management 
facility called XM that is available 
with the Toolset and the Work¬ 
bench. It allows for programs requir¬ 
ing more space than DOS provides 
under the 640 KB barrier. However, 
you should be familiar with the use 
of relocatable .GNT or .INT code 
and the runtime environment pro¬ 
vided by the Toolset and Workbench 
products before creating applications 
too large for the available memory 
in DOS. Micro Focus COBOL/2 
DOS Database Requester applica¬ 
tions can be developed with no more 
effort than that required to develop 
an OS/2 database requester applica¬ 
tion. You must ensure that the 
COBOL/2 environment is using 
DOS. Once Micro Focus COBOL/2 
is set up, you should find its environ¬ 
ment very robust for developing 
DOS Database Requester applica¬ 
tions, and you will be able to use the 
Micro Focus tools available for 
COBOL application development. 


ABOUT THE AUTHOR 

Andrew Morbitzer is part of IBM's 
OS/2 Application Assistance Center 
team , working through the 
cooperative education program. He 
spends much of his time on OS/2 
Database Manager performance and 
problem management at customer 
locations. He holds a B.B.A. in 
management information systems 
from Texas A&M University and is 
currently studying for his M.B.A. in 
business computer information 
systems at the University of North 
Texas. 


Personal Systems/Issue 4, 1991 



52 


IDENTIFICATION DIVISION. 

PROGRAM-ID. DOS-DB-REQUESTER. 

*********************************************************************************** 

* This COBOL program is an example of how to catalog a remote 

* database from a DOS Database Requester. 
*********************************************************************************** 


ENVIRONMENT DIVISION. 

DATA DIVISION. 

WORKING-STORAGE SECTION. 

*********************************************************************************** 
* SQLCA * ************** 

EXEC SQL INCLUDE SQLCA END-EXEC. 

* SQLENV * 

* The SQLENV_ is special to the DOS DB Requester. The OS/2 SQLENV * 

* does not include the underscore character. When the .CBL file * 

* is compiled on the DOS machine, this file will be copied from * 

* the \DBDRQLIB directory. * 

+*****************+*************+***■*+■*+********************+++*+********+********* 


COPY SQLENV_. 

ic+it*icirieicicic***+icicic*iriciricir+ic*-k-k*i'**ic**iricir*iciciticiri(-kicic-k-k-k-kic-k-k-jc-k-kic'k'k'k-k-ie*'kie'k-i:ieic*-k-k'k-k-k-k-k-k-k-k-k 

* VARIABLES TO PASS TO CALLS * 

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 


77 COMMENT-LENGTH PIC S9(4) 
77 NN-LENGTH PIC S9(4) 
77 ALIAS-LENGTH PIC S9(4) 
77 DB-LENGTH PIC S9(4) 
77 CMT-CODE-PAGE PIC S9(4) 


VALUE 22 
VALUE 8 
VALUE 6 
VALUE 6 
VALUE 0 


COMP-5. 

COMP-5. 

COMP-5. 

COMP-5. 

COMP-5. 


*********ici'+-k**ie*******iric*iririric*iciric*ir-k**-k-k-k'k*ic-k'k'k'k*-k’k-kic’k-k-k-k'k*-k'k-k-k’k-k-k-k-k-k-k'k-k-kic-k-k'k'k-k-k-k-k 

* I used DRIVE so that my example will use the same variable names as the * 

* IBM OS/2 Extended Edition 1.3 Database Manager Programming Guide and * 

* Reference Volume 2: Reference on page 3-11. However, the DRIVE should * 

* contain the reference to either adapter 0 or 1 for a DOS DB Requester. * 

*********************************************************************************** 


77 

D 

PIC X. 

77 

DRIVE 

REDEFINES D 
PIC 9(4) 

77 

T 

PIC X. 

77 

DTYPE 

REDEFINES T 
PIC 9(4) 

77 

COMMENT 

PIC X(23) 

77 

NODE-NAME 

PIC X(9) 

77 

ALIAS 

PIC X(7 ) 

77 

DATABASE 

PIC X(7) 

PROCEDURE DIVISION. 

PERFORM 7000-CATAL0G 


COMP-5. 


COMP-5. 

VALUE ’REMOTE SAMPLE DATABASE’. 
VALUE ’ ANDREWCM*. 

VALUE 'SAMPLE’. 

VALUE ’SAMPLE’. 


Figure la. Sample Program 
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THRU 7000-EXIT. 

PERFORM 8000-TERMINATE 
THRU 8000-EXIT. 

STOP RUN. 

7000-CATALOG. 

********************************************************************************** 

* The following MOVE statements move 0 for the adapter number to D * 

* and move 1 to database type T. The database type of 1 indicates * 

* a remote database. The database type is for an OS/2 requester and * 

* is not used by DOS DB Requester. * 


MOVE 0 TO D. 

MOVE 1 TO T. 

********************************************************************************** 

* The COBOL form of the following call to catalog a remote database is * 

* shown on page 6-17 of the IBM OS/2 Extended Edition Version 1.3 * 

* Database Manager Programming Guide and Reference Volume 2: Reference. * 

********************************************************************************** 


CALL “_SQLGCATD” USING DATABASE 

ALIAS 

NODE-NAME 

COMMENT 

SQLCA 

BY VALUE DTYPE 
BY VALUE CMT-CODE-PAGE 
BY VALUE DRIVE 
BY VALUE DB-LENGTH 
BY VALUE ALIAS-LENGTH 
BY VALUE NN-LENGTH 
BY VALUE COMMENT-LENGTH. 

DISPLAY 'This is the SQLCODE from Cataloging - ’ SQLCODE. 

7000-EXIT. 

EXIT. 

8000-TERMINATE. 

IF SQLCODE = 0 

DISPLAY ’The program has ended normally’ 

ELSE 

GO TO 9000-SQL-ERR0R. 

MOVE 0 TO RETURN-CODE. 

8000-EXIT. 

EXIT. 

9000-SQL-ERROR. 

DISPLAY * A fatal SQL error has occured with SQLCODE:' SQLCODE. 
DISPLAY 'The program has ABNORMALLY ended’. 

GOBACK. 


Figure lb. Sample Program 
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IBM DOS 5.0 
Facts and 
Features 

Midge Fortney 
IBM Corporation 
Boca Raton , Florida 

If you are a DOS user and have ex¬ 
perienced RAM CRAM (not 
enough room in conventional 
memory to run everything you 
want to run at the same time), 
then IBM DOS 5.0, the tenth and 
latest version of IBM’s single task¬ 
ing operating system, is for you. 

Memory, memory, memory. . . . 
Memory relief with DOS 5.0 can be 
quite dramatic. If your system is an 
80286 or higher with at least 1 MB 
of memory, parts of DOS can be 
moved into an area outside of the 
conventional 640 KB memory area. 
This means your operating system is 
using less than 20 KB of conven¬ 
tional memory. For other hardware, 
DOS 5.0 is approximately 49 KB, 
using a little more memory than 
DOS 3.3, but less than DOS 4.0. 

IBM DOS 5.0 replaces and is up¬ 
wardly compatible with IBM DOS 
3.3 and IBM DOS 4.0. The features 
of DOS 5.0 are improved memory 
and file management, and improved 
and expanded utilities. 

DOS 5.0 is available in two separate 
packages: 

• The IBM DOS 5.0 Upgrade (U.S. 
offering) for U.S. users who have 
a previous level of IBM DOS 
(between 2.1 and 4.0) installed on 
the fixed disks of their IBM sys¬ 
tems. The upgrade is priced at 
about one-half of the base DOS 
product price. Once the upgrade 
is installed, the DOS 5.0 code is 


the same as the base DOS 5.0 
product. 

• The IBM DOS 5.0 base product 
(worldwide offering) is for U.S. 
users who do not have a previous 
level of IBM DOS (between 2.1 
and 4.0) already installed on the 
fixed disks of their IBM systems 
and all IBM DOS non-U.S. cus¬ 
tomers. European countries offer 
the IBM DOS 5.0 base product at 
full and upgrade prices. 

Installation 

Installation of both DOS packages is 
simple: the user inserts diskette #1 
in the A drive and reboots. The de¬ 
fault configuration puts DOS into 
the high memory area and loads 
SETVER.EXE. (SETVER allows ap¬ 
plications designed for a specific ver¬ 
sion of DOS to run on DOS 5.0.) 

When the IBM DOS 5.0 Upgrade is 
used, the existing AUTOEXEC.BAT 
and CONFIG.SYS get merged with 
these statements. In addition, the de¬ 
fault configuration makes DOS 
come up under the DOS Shell. 

If you boot your system with the de¬ 
fault configuration that is created 
when you first install the base pack¬ 
age, you will be surprised and de¬ 
lighted to find 616 KB of available 
memory. 

Memory Management 

DOS 5.0 includes two memory man¬ 
agement device drivers that are 
based on older versions distributed 
with DOS LAN Requester and Mi¬ 
crosoft® Windows™ 3.0. Because 
the device drivers have been im¬ 
proved for DOS 5.0, make sure you 
use these new versions instead of 
the ones supplied with Microsoft 
Windows 3.0 or DOS LAN 
Requester. 


• HIMEM.SYS manages the use of 
extended memory according to 
the Extended Memory Specifica¬ 
tion (XMS). This includes the 
high memory area (HMA), which 
is where DOS will be loaded. 
(HMA is the first 64 KB of ex¬ 
tended memory above 1MB.) 
This driver must be loaded before 
loading any other device drivers 
that use extended memory (such 
as SMARTDRV.SYS, 
RAMDRIVE.SYS, and 
EMM386.EXE). 

• EMM386.EXE uses extended 
memory to emulate expanded 
memory only on 80386 and 
higher systems. You must have 
HIMEM.SYS loaded before this 
driver can be used. (The default 
amount is 256 KB, but you will 
probably want to increase it.) 
EMM386.EXE replaces 
XMAEM.EXE and 
XMA2EMS.EXE. 

Upper Memory Block: The upper 
memory block (UMB) area is the 
area between 640 KB and 1 MB. Al¬ 
though this entire area is reserved 
for hardware, expanded memory 
pages, and video buffers, once the 
system is fully configured there are 
some areas that are unused. DOS 5.0 
can use these areas to load either de¬ 
vice drivers or terminate-and-stay- 
resident (TSR) programs, thereby 
freeing up conventional memory 
(the first 640 KB of memory). You 
must have EMM386.EXE loaded to 
use this area, and it is used only on 
80386 and higher systems. 

The DOS device drivers that can be 
loaded in this area (using the 
DEVICEHIGH command) are: 

• EGA.SYS 

• DISPLAY.SYS 

• ANSI.SYS 

• RAMDRIVE.SYS 
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Two of these drivers are new with 

DOS 5.0: 

• RAMDRIVE.SYS creates a tem¬ 
porary disk in RAM, or conven¬ 
tional memory. Use /E to create 
the disk in extended memory and 
/A to create it in expanded 
memory. 

This replaces VDISK.SYS. 

• SMARTDRV.SYS creates a disk 
cache in extended or expanded 
memory. This replaces 
1BMCACHE.SYS. 



The DOS TSR programs that can be 
loaded in the UMB area (using the 
LOADHIGH command) are: 

• DOSKEY.COM 

• MOUSE.COM 

• DOSSHELL.COM 

• KEYB.COM 

• GRAPHICS.COM 

• NLSFUNC.EXE 

• MODE.COM 

• SHARE.EXE 

• PRINT.EXE 

• APPEND.EXE 

The CONFIG.SYS file must have 
the following sequence before the 
UMB area can be used: 

DEVICE=C:\DOS\HIMEM.SYS 
DOS-HIGH.UMB 

DEVICE=C:\DOS\EMM386.EXE 
NOEMS (or RAM) 
DEVICEHIGH=mydriver.sys 

Place the LOADHIGH statements in 
the AUTOEXEC.BAT: 

LOADHIGH myprog.exe 


To fully utilize the UMB area, load 
the largest drivers and/or programs 
first, because DOS will use the larg¬ 
est space as the “HIGH” commands 
are processed sequentially. 

To obtain a memory map, use 
MEM /C; to view the memory us¬ 
age, use MEM/DEBUG; to print, 
use MEM /C > LPT1. 

If you are using a VGA color dis¬ 
play in graphics mode, you can use 
the area normally reserved for the 
monochrome display (B000-B7FF). 

If you don’t run BASIC programs or 
use the DOS 5.0 full-screen editor, 
you can use the IBM BASIC ROM 
area (F600-FDFF) (except on the 
PS/2 Model 57). When using these 
with EMM386.EXE, include parame¬ 
ter (I=B000-B7FF I=F600-FDFF) to 
increase your UMB space by 64 KB. 

In addition, use your system’s refer¬ 
ence diskette to consolidate the vari¬ 
ous adapter BIOS and data areas. 

For example, for XGA and Token- 
Ring (16/4), change the token ring 


adapter addresses from DOOO to 
COOO. 

DOS Shell 

The DOS Shell on IBM DOS 5.0 
can perform application context 
switching in a suspend/resume 
mode. The applications must be 
loaded within the DOS Shell. These 
applications are swapped to disk or 
to extended memory. 

Some DOS Shell highlights are: 

• Active task list 

• View of directories on the current 
disk 

• View of several directories at one 
time 

• Ability to rename a directory 

• Look and feel of OS/2 Presenta¬ 
tion Manager and Windows 3.0 

Differences between 
DOS 5.0 and DOS 4.0 

Most of the DOS 5.0 files are com¬ 
pressed (as denoted by an under¬ 
score in the file extension) on 
the diskettes. In order to use them. 
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they must be expanded using the 
new EXPAND.EXE utility. 

In DOS 4.0, ANSI.SYS has a switch 
/L, which keeps the number of rows 
set by the mode command as you 
switch between text and graphics ap¬ 
plications. Because of its many in¬ 
compatibilities with some 
applications, this support was elimi¬ 
nated from DOS 5.0. 

VDISK.SYS has been replaced by 
RAMDRIVE.SYS, which has the 
same function. Any programs that 
used VDISK.SYS should be updated 
to use RAMDRIVE.SYS. 

DOS 5.0 has two BASIC programs: 
QBasic and BASICA. In order for 
QBasic to run BASICA programs, 
the BASICA programs must be 
saved in ASCII mode, using the 
command: 

(SAVE "filename”. A). 

In BASICA, the default is to save a 
file in binary mode. 

BASICA in DOS 5.0 is larger than 
in DOS 4.0, because it will support 
PS/2 systems with less BASIC code 
in the BIOS, such as the PS/2 Model 
57. Previous PS/2 models contained 
32 KB of BASIC in BIOS. Newer 
machines contain only 5 KB, and 
that code now resides in the 
BASICA.COM file. 

The expanded memory device 
drivers XMA2EMS.SYS and 
XMAEM.SYS have been replaced 
by the higher performance 
EMM386.EXE. As the name im¬ 
plies, EMM386.EXE only has sup¬ 
port for memory on 80386 systems. 

If IBM XMA adapter support is 
needed for an 80286 system, the 
XMA2EMS.SYS file can be ob¬ 
tained through IBM DOS 5.0 serv¬ 
ice. If you have a non-IBM memory 


adapter (EMS 3.2 or 4.0), use the 
driver supplied by the manufacturer. 

If your mouse doesn’t work properly 
with the DOS 5.0 Shell, you may 
need the new MOUSE.COM version 
7.04, which is supplied with DOS 
5.0 but doesn’t get installed automat¬ 
ically. Installation information is 
found in the Getting Started manual. 

The DOS 5.0 Shell doesn’t recog¬ 
nize the .MEU extension of files cre¬ 
ated by the DOS 4.0 Shell. The 
utility MEUTOINI will convert 
these files for you. If you are install¬ 
ing the upgrade, it will be run auto¬ 
matically. Changes have been made 
to functions of the Shell, and certain 
installation switches are no longer 
supported. Further information is 
found in the Getting Started manual. 

In DOS 4.0, SHARE was loaded 
automatically to support hardfile par¬ 
titions of greater than 32 MB. DOS 
5.0 has improved partition support, 
with a savings of 8 KB, and no 
longer requires SHARE. 

New and Enhanced Utilities 

Here are the new utilities in 
DOS 5.0: 

• Doskey provides command line 
history and macro capability. 

• Unformat complements the new 
safe format. 

• Undelete has the ability to re¬ 
cover deleted files. 

• Fc is a second file compare utility 
that compares two files of differ¬ 
ent sizes. 

• Setver allows applications to 
think there is a different level of 
DOS on the system. (For in¬ 
stance, some applications require 
DOS 3.3.) 

Here are the enhanced utilities in 
DOS 5.0: 


• Dir has sort options, attribute fil¬ 
ter, and DIR/SUBDIR file matches 

• Format has safe format as the de¬ 
fault and saves control data. 

There is also a quick format 
option. 

• Attrib allows the manipulation of 
system and hidden files 

• Restore has a /D option that will 
allow users to view the backed-up 
file list. 

OS/2 Dual Boot 

When installing DOS 5.0 on a dual 
boot system, before leaving the 
OS/2 command prompt, you must 
point to the DOS directories by typ¬ 
ing BOOT /DOS. In addition, dur¬ 
ing the installation, if you are asked 
if you want to replace all occur¬ 
rences of your files, say “NO” be¬ 
cause some DOS and OS/2 files 
have the same name. A DOS FAT 
partition must be located before an 
OS/2 high performance file system 
(HPFS). 

OS/2 Upgrades 

When OS/2 2.0 becomes available, 
you will be able to upgrade your 
DOS 5.0 to OS/2 2.0. 

DOS 5.0 and PS/1™ 

To install DOS 5.0 on a PS/1, the en¬ 
vironment must point to the fixed 
disk instead of to ROM DOS, so 
that you can start your PS/1 from 
fixed disk instead of from ROM. 
There are certain things you need to 
know, so refer to the PS/1 documen¬ 
tation before installing DOS 5.0. 

Your ROM Shell will no longer 
work. 

DOS 5.0 Changing Hardfile 
Partition Size 

If you have a fixed disk that is 
larger than 32 MB and is partitioned 
to 32 MB with your current version 
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of IBM DOS, you may repartition 
the fixed disk to any size. Install 
DOS 5.0 over your current version 
of IBM DOS. Although the upgrade 
was designed for this, you may also 
use the base DOS 5.0 program. If 
you are using the upgrade, back up 
your current level of DOS with the 
backup option of the install. Once 
DOS 5.0 is installed, try it out and 
make sure that it works to your satis¬ 
faction. Then do a complete backup 
of all of the disk partitions on your 
fixed disk using the BACKUP 
command. 

Create a boot diskette in the A drive 
by formatting a blank diskette with 
/S. Also on the diskette, copy 
FDISK, FORMAT, and RESTORE 
from your DOS 5.0 subdirectory. 
Copy your favorite editor, too. (If 
you choose the editor on DOS 5.0, 
copy over QBASIC.EXE and 
EDIT.COM.) Remove the diskette 
from the A drive. Use FDISK to set 
up your new partition (you will be 
erasing your fixed disk, so make 
sure you backed it up). This will in¬ 
struct you to restart DOS with the 
boot diskette in the A drive. 

Once you have restarted the ma¬ 
chine, run FORMAT /S from the 
boot diskette and format your 
hardfile. Then you can reinstall DOS 
5.0 using your DOS 5.0 program. Af¬ 
ter it is installed, do a RESTORE of 
your backup diskettes. Use caution 
if you’ve had identical subdirectory 
names on different disk partitions. 

DOS 5.0 and 7552 Industrial 
Gearbox™ 

A special parameter with the 
HIMEM device driver is required in 
the CONFIG.SYS to load DOS 
HIGH on the IBM Industrial Com¬ 
puter Model 7552. When you have 
completed the initial DOS 5.0 instal¬ 
lation, before you use Ctl-Alt-Del to 


reboot, press F3 to get out of the 
installation procedure, put the first 
DOS 5.0 diskette in the A drive, and 
edit CONFIG.SYS in the root of C 
to include this parameter: 

DEVICE = C:\D0S\HIMEM.SYS 
/MACHINE:15 

If you have HIMEM.SYS loaded 
without /MACHINE: 15, the 7552 
Industrial Gearbox will hang when 
you try to boot your system. 

All other industrial computers will 
work fine as installed. 



A new feature, command 
line help, is accessed by 
entering help or the 
command name followed 
by n. 


Online Documentation 

To help you understand DOS 5.0 bet¬ 
ter, files with compatibility and how¬ 
to information are provided. In 
addition, there is an important file 
(on diskette #2 of the 3.5” package 
and diskette #3 of the 5.25" pack¬ 
age) called the PACKING.LST file. 
This file tells you on which diskettes 
all of the DOS files are located. (If 
you are installing to diskette, it will 
also tell you which files are on the 
target diskettes.) 

README.TXT has the latest on¬ 
line information. It contains addi¬ 
tional information on memory, 

OS/2, Windows, mouse drivers, and 
different networks. 

APPNOTES.TXT will help you run 
existing applications with DOS 5.0. 


It gives you tips and techniques to 
get maximum productivity as 
quickly as possible with this latest 
version of DOS. 

A new feature, command line help, 
is accessed by entering help or the 
command name followed by /?. 
“Help” lists all the commands and 
their functions. Can’t remember the 
syntax for the del command? Type 

del /? 

and not only will you get a brief ex¬ 
planation, but the permissible syntax 
functions, as well. 

The installation feature has function 
keys that give you help or allow you 
to return to a previous screen or exit 
the program. The help is so com¬ 
plete you may never have to open 
the documentation. To start the in¬ 
stallation, just put diskette #1 of the 
DOS 5.0 or the DOS 5.0 Upgrade in 
your computer and start your system 
(Ctl-Alt-Del). 

You will enjoy losing yourself in the 
levels of DOS Shell help, and it is 
equally accessible with the mouse or 
keyboard. Put your book away and 
prepare for an online adventure! 

For upward compatibility, BASICA 
(BASIC interpreter) and EDLIN 
(line editor) continue to be available. 
A second BASIC interpreter pro¬ 
gram, QBasic, with advanced fea¬ 
tures and a full-screen editor, EDIT, 
are exciting additions to the product. 
To find out some of the differences 
between QBasic and BASICA, and 
the conversion requirements to use 
QBasic to run your BASICA pro¬ 
grams, look at the “Survival Guide,” 
which is the first screen after invok¬ 
ing QBasic. Choose “Contents,” and 
then “Converting BASICA Pro¬ 
grams.” (DOS 5.0 has a program, 
REMLINE.BAS, that helps in the 
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conversion.) Working through these 
screens gives you a lot of informa¬ 
tion that will make you comfortable 
with QBasic without ever opening a 
book! All documentation for QBasic 
is online. 

Although the full-screen editor is 
part of QBasic, you can type "edit” 
to start it, without going into QBasic 
first. It is a text-mode editor with 
block and line marking, has mouse 
support, and full online 
documentation. 

Service 

A good service and support structure 
is a key priority. Users want to be 
able to ask questions - quickly and 
easily. IBM has broadly expanded 
service and support to include both a 
toll-free number and access to an 
Electronic Bulletin Board. The toll- 
free number is 1 800 237-5511 and 
the customer number is DOS 5692. 
Corrective Service Diskettes will be 
available at your IBM Authorized 
Dealer, through the toll-free number, 
IBM branch offices, or the Elec¬ 
tronic Bulletin Board (National Sup¬ 
port Center, Atlanta, 404 835-6600). 
The DOS 5.0 service information 
card gives details about the en¬ 
hanced service. 

National Language Support 

Ever want to send a letter to some¬ 
one in Turkey? Your U.S. version of 
IBM DOS 5.0 supports Turkish char¬ 
acters as well as a host of others. A 
small booklet titled Keyboards and 
Code Pages is included with DOS 
5.0. This booklet has keyboard lay¬ 
outs (when you choose to write with 
Turkish characters, your keyboard 
layout will change), code page ta¬ 
bles, and available accented 
characters. 


DOS 5.0 and Network 
Support 

With each new version of DOS, 
your network must be modified ac¬ 
cordingly. The network code needed 
to use DOS 5.0 with the IBM PC 
LAN program, IBM DOS LAN Re¬ 
quester, or Novell NetWare is in¬ 
cluded in the IBM DOS 5.0 
Upgrade. This is the first time that 
DOS is supplying network support 
in its initial offering. If you have an¬ 
other type of network, call IBM 
Service or your network supplier. 



Although the full-screen 
editor is part of QBasic, 
you can type “edit” to 
start it, without going into 
QBasic first. 


Hardware Support 

The following new hardware fea¬ 
tures are supported in DOS 5.0: 

• The new 2.88 MB 1-inch high 
diskette drives are high-density 
(2.88 MB, also known as 4 MB) 
3.5-inch diskette drives. These all 
have media-sensing capability. 

• Some models of 1.44 MB and 
2.88 MB diskette drives have me¬ 
dia-sensing capability. With this 
feature, when you format a disk¬ 
ette, the system recognizes the 
type of diskette in the drive and 
formats it accordingly. Pre¬ 
viously, the FORMAT command 
was used to format a diskette ac¬ 
cording to the size of the drive 
containing the diskette. For exam¬ 
ple, a 1.44 MB diskette drive for¬ 
matted a 720 KB diskette 
incorrectly as 1.44 MB. The de¬ 


fault in the FORMAT statement 
was the size of the drive. This 
could cause data errors. With me¬ 
dia-sensing, such errors are 
prevented. 

• The 3.5-inch Read/Write Optical 
Disks are new IBM products that 
allow large amounts of data to be 
stored on an optical disk. New 
multimedia sound and motion 
technology, which requires vast 
amounts of data, is one of the 
many uses for these disks. 

• Keyboards that now have DOS 
5.0 support include the 122-key 
host-connected PS/2 keyboard 
and the 106-key Japanese 
keyboard. 

Extended DOS Support 

ACCESS DOS is a supplement to 
IBM DOS 5.0 that provides ex¬ 
tended keyboard, mouse, and sound 
access for IBM DOS users. It is very 
helpful for people with disabilities. 
Here are some features: 

• Sticky keys - allow sequential 
rather than simultaneous process¬ 
ing of keystrokes (like 
Ctl-Alt-Del) 

• Mouse keys - allow the numeric 
keypad to perform like a mouse 

• Repeat keys - customize how fast 
held-down keys repeat 

• Slow keys - customize the length 
of time a key is pressed before it 
is processed 

• Bounce keys - prevent double 
characters from being processed 

• Serial keys - allow control of the 
keyboard and mouse through an 
input device (not included) 

• Toggle keys - use beeps to indi¬ 
cate when Caps, Num, and Scroll 
Lock keys are activated 
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This supplement is available free of 
charge through IBM. Call 
1 800 IBM-2468. 

IBM DOS 5,0 and 
MS-DOS® 5.0 Upgrade 

What are the differences between 
IBM DOS 5.0 and Microsoft’s MS- 
DOS Upgrade? Both IBM DOS and 
MS-DOS, once installed, have the 
same commands and essentially the 
same documentation. But IBM has 
“customized” the generic MS-DOS. 

MS-DOS 5.0 is offered only as an 
upgrade to a previous DOS system. 
IBM offers the choice of the DOS 
Upgrade, which is competitively 
priced, and the base DOS 5.0, for us¬ 
ers who do not already have DOS 
installed. The base DOS will also 
work on systems that have a pre¬ 
vious level of IBM DOS installed. 

MS-DOS has been tested on clone 
hardware thoroughly; IBM has gone 
a step further in testing IBM DOS 
on IBM hardware. 

Install: MS-DOS 5.0 and IBM 
DOS 5.0 both offer upgrades to an 
existing DOS system. IBM DOS Up¬ 
grade is self-booting, installs only 
over an existing IBM DOS from 2.1 
through 4.0, and will not install to 
diskettes. In addition, IBM DOS 5.0 
Upgrade requires you to have IBM 
hardware. If you are a user of IBM 
DOS prior to DOS 2.1 or an IBM 
DOS user with a diskette-only con¬ 
figuration, you can call 1 800 IBM- 
7699 to purchase a copy of the full 
package at the Upgrade price. MS- 
DOS does not check for any of these 
things except for the existence of a 
prior DOS. It does this by running 
the install as an application (your 
system must be running before you 
can start the MS-DOS install by typ¬ 
ing A:SETUP). MS-DOS 5.0 Up¬ 


grade will install to either fixed disk 
or diskette. 

MS-DOS will install across a LAN. 

Hardware: Although MS-DOS 5.0 
Upgrade will install to all systems 
and IBM DOS, once installed, is 
only warranted on IBM hardware, 
the base IBM code is functionally 
the same (except for BASICA, 
QBasic, and EDIT). QBasic and 
EDIT may require an update from 
IBM. Please see additional informa¬ 
tion under “BASIC/Editor.” If a 
problem is found using IBM DOS 
on clone hardware, the user can call 
IBM for service and support. If, af¬ 
ter analysis, IBM determines that it 
is not a problem in the IBM DOS 
product, then IBM refers the user to 
the appropriate hardware vendor. 



Both IBM DOS and 
MS-DOS, once installed, 
have the same commands, 
and essentially the same 
documentation. But IBM 
has “customized” the 
generic MS-DOS. 


Remote IPL: There are some differ¬ 
ences that may affect the user. The 
“hidden” files IBMBIO.COM and 
IBMDOS.COM are known as 
IO.SYS and MSDOS.SYS in MS- 
DOS 5.0. This difference affects the 
remote IPL feature (RIPL). IBM 
DOS may be installed by an OS/2 
LAN Server for use by DOS RIPL 
machines without having to create 
separate boot images for each work¬ 
station. Because the MS-DOS sys¬ 
tem file names are different (IO.SYS 
and MSDOS.SYS), the boot images 


can be created and RIPL’d with MS- 
DOS diskettes; however, OS/2 LAN 
Server’s “parameter passing” feature 
(to allow workstations to use the 
same image) does not work. 

BASIC/Editor: MS-DOS ships 
with only QBasic, and even though 
prior versions had GW-BASIC (simi¬ 
lar to BASICA), it is no longer 
shipped with DOS 5.0. If IBM DOS 
5.0 is installed on non-IBM hard¬ 
ware, an updated QBasic is required 
for QBasic and EDIT (the full¬ 
screen editor) to run properly. 
BASICA will not work on non-IBM 
hardware. If you do not have 
QBASIC.EXE dated 8/16/91 or 
later, please call IBM Service. You 
can also get this module from your 
dealer, your IBM branch office, or 
the Electronic Bulletin Board. 

Support Unique to IBM: 

8514A - Using MS-DOS 5.0 with a 
color display and the IBM 8514A 
adapter, the install and DOS Shell 
come up in monochrome. IBM DOS 
works properly in these 
environments. 

CD-ROM SETVER - Users should 
make sure the following statement is 
added to the SETVER table if they 
are using IBM DOS 5.0 (MS-DOS 
has it included). 

SETVER MSCDEX.EXE 4.00 

SHELL/MOUSE support - For users 
of DOS 4.0, there is a conversion 
utility that will update the MEU 
files to the IBM DOS Shell 5.0 for¬ 
mat. In addition, the 5.0 Shell-com¬ 
patible mouse is included in IBM 
DOS 5.0, although this is available 
through MS support. 

4755 Cryptographic adapter with 
EMM386 - IBM DOS 5.0 supports 
the use of the 4755 Cryptographic 
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adapter if EMM386 is loaded. MS- 
DOS does not. 

National Language Support - Coun¬ 
try support for Greece, Turkey, and 
Iceland are available in IBM DOS 
5.0, but not in MS-DOS 5.0. 

Corrective Service Diskettes 
(CSD): IBM has a policy of issuing 
CSDs periodically to better serve 
customer needs. In the past Mi¬ 
crosoft has not provided this. 

Uninstall Option: During installa¬ 
tion, the IBM DOS 5.0 Upgrade 
gives the user the option of creating 
(or not creating) UNINSTALL disk¬ 
ettes. MS-DOS does not give the 
user this option; the user must copy 
some of the “old DOS” files onto 
diskettes. MS-DOS also copies 
many of the “old DOS” files into a 
separate directory of the fixed disk, 
limiting available fixed disk space. 

Bootable Diskettes: MS-DOS 5.0 
diskettes are not bootable, but rather, 
are run as an application. This 
means enough memory has to be 
available, with a stable environment, 
to ensure smooth installation. Be¬ 
cause both IBM DOS 5.0 products 
are bootable, this is not a problem 
for the IBM products. 

The IBM DOS self-booting feature 
is valuable for the repartitioning of 
hard disk drives and for recovering 
from computer viruses. 

Network Support: IBM DOS 5.0 
Upgrade contains full Novell Net¬ 
Ware drivers, including EMS and 
XMS support. MS-DOS upgrades 
only the base memory driver from 
Novell; therefore, the memory you 
save with MS-DOS 5.0 is used for 
the Novell drivers. With IBM DOS, 
you achieve memory savings and get 


the memory management Novell 
drivers. 

Drivers for 3COM networks and 
LAN MAN networks are included in 
MS-DOS. These drivers are also 
available on CompuServe in the 
MSNETWORKS forum, library one, 
supplemental disks. Try searching 
for “supp.” Call 3COM for addi¬ 
tional information on the 3COM net¬ 
work products. 

To use IBM DOS 5.0 with Banyan 
Vines 4.0X, on the command line 
type SETVER REDIR4.EXE 4.0. 
MS-DOS 5.0 already has this state¬ 
ment in the SETVER table. Banyan 
Vines 4.10 has DOS 5.0 support and 
is available. 


The IBM DOS 
self-booting feature is 
valuable for the 
repartitioning of hard 
disk drives and for 
recovering from computer 
viruses. 

Service: The service philosophies 
of IBM and MS differ; each sup¬ 
ports the customer a little differ¬ 
ently. IBM offers free service for 
one year, while Microsoft offers it 
for three months. IBM Corrective 
Service Diskettes are cumulative 
fixes available to all customers. Mi¬ 
crosoft corrective service is a single 
fix to a customer with a problem, 
and Microsoft uses CompuServe to 
make certain fixes available to 
customers. 


The End User Bulletin Board for 
IBM is Electronic BBS and 
NSC/Atlanta, while Microsoft uses 
CompuServe. Both Microsoft and 
IBM have 24-hour/7-day phone num¬ 
bers to report a problem. The IBM 
Support Center number is 1 800 237- 
5511; the MS Automated Support 
System number is 1 800 646-5103. 

For technician support, IBM has pro¬ 
gramming services available Mon¬ 
day through Friday for 8 hours per 
day for 1 year (1 800 237-5511); Mi¬ 
crosoft has Technician support Mon¬ 
day through Friday 8 hours per day 
for 90 days, with support after 90 
days at $2 per minute (1 900 896- 
9000) or $20 per call (206 646- 
5108). 
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The information about MS-DOS 5.0 
Upgrade, IBM DOS 5.0, and IBM 
DOS 5.0 Upgrade is based upon infor¬ 
mation and packages available on June 
11, 1991, the time these products were 
announced. All references to MS-DOS 
5.0 or MS-DOS refer to the MS-DOS 
5.0 Upgrade. All references to IBM 
DOS 5.0 or IBM DOS refer to both 
base and upgrade products unless 
otherwise specified. 
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IBM DOS 5.0 
Upgrade 

Pylee Lennil and 
Clovis L. Tondo 
IBM Corporation 
Boca Raton , Florida 

The IBM DOS 5.0 Upgrade allows 
DOS users to upgrade their cur¬ 
rent versions of IBM DOS to IBM 
DOS 5.0. The Upgrade is less ex¬ 
pensive than the DOS 5.0 Base In¬ 
stallation program and is 
designed for users who already 
have IBM DOS installed. 

The DOS 5.0 Upgrade has several fa¬ 
cilities to help the user upgrade from 
an earlier DOS version. The package: 

• Allows users to back up the old 
version of DOS onto diskettes be¬ 
fore installing DOS 5.0 

• Allows users to restore the old 
DOS from backup diskettes 

• Upgrades the DOS CONFIG.SYS 
and AUTOEXEC.BAT files to 
conform to the DOS 5.0 
CONFIG.SYS and 
AUTOEXEC.BAT file standards 

• Upgrades the DOS 4.0 shell menu 
files to DOS 5.0 shell menu file 
format 

• Allows users to replace all occur¬ 
rences of their DOS system files 

• Provides network update files for 
PC LAN Program and Novell 
networks 

Backing Up the Old DOS 

The DOS 5.0 Upgrade allows users 
to back up DOS versions 2.1 
through 5.0 onto diskettes before in¬ 
stalling DOS 5.0. When the upgrade 
program starts, a backup menu is dis¬ 
played. If the user chooses to back 
up the old system, the program cop¬ 
ies the old DOS files to the backup 


diskettes. If necessary, the user can 
restore the old DOS version from 
the backup diskettes using the Unin¬ 
stall feature. 

Restoring the Old DOS 

The Upgrade allows users to restore 
the old DOS, which was previously 
saved using the backup facility. The 
program displays the Uninstall 
menu. If the Uninstall option is se¬ 
lected, the program requests that the 
first backup diskette is inserted and 
DOS 5.0 is removed from the fixed 
disk. Then it reboots the system. An 
internal procedure restores the old 
DOS from the backup diskettes. 


It is important to note that users 
must go through the Uninstall proce¬ 
dure to uninstall DOS 5.0. This is be¬ 
cause the boot record for earlier 
versions of DOS is somewhat differ¬ 
ent, and it is necessary to use the Up¬ 
grade to restore the boot record and 
the files. 

Upgrading CONFIG.SYS 
and AUTOEXEC.BAT 

The Upgrade allows users to up¬ 
grade the existing CONFIG.SYS 
and AUTOEXEC.BAT files after 
copying the DOS 5.0 system files to 
the disk. The upgrade involves mak¬ 
ing the necessary changes to these 
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Default version for 
CONFIG.SYS 

DEVICE-Cr\DOS\SETVER.EXE 
DEV ICE-C:\D0S\HIMEM.SYS 
DOS-HIGH 
FILES-10 

Default version for 
AUTOEXEC.BAT 

@ECH0 OFF 
PROMPT $p$g 
PATH-C:\D0S 
SET TEMP-C:\D0S 
C:\DOS\DOSSHELL.EXE 


Figure 1. Defaults 


files to conform to the DOS 5.0 
CONFIG.SYS and 
AUTOEXEC.BAT standards. The 
changes are necessary because DOS 
5.0 has some new commands, and 
some existing commands were modi¬ 
fied. The program copies the 
CONFIG.SYS and 
AUTOEXEC.BAT files to the 
CONFIG.DAT and 
AUTOEXEC.DAT files, respec¬ 
tively, before it upgrades those files 
to DOS 5.0 standards. The 
CONFIG.SYS and 
AUTOEXEC.BAT file modifica¬ 
tions are necessary because of the 
following changes: 

• These commands were removed 
from DOS 5.0: 

— INSTALL-IFSFUNC.EXE 
— INSTALL=FILESYS.EXE 

• These commands were added in 
DOS 5.0: 

- DEVICE-SETVER.EXE 
— DEVICE-SMARTDRV.SYS 
— DOS-HIGH 
— Note that 

DEVICE-SETVER.EXE 

provides version changes to 
programs; 


DEVICE-HIMEM.SYS 

and 

DOS-HIGH 

load DOS into high memory 
area. 

• These commands were replaced 
by new commands: 

— DEVICE-XMAEM.SYS 

and 

DEVICE-XMA2EMS.SYS 
were replaced by 
DEVICE-EMM386.EXE 
(Note that 

DEVICE-XMA2EMS.SYS 

still is required for 80286 sys¬ 
tems with expanded memory 
adapter hardware.) 

- DEVICE-IBMCACHE.SYS 
was replaced by 
DEVICE-SMARTDRV.SYS 

- DEVICE—VDISK.SYS 


was replaced by 

DEVICE-RAMDRIVE.SYS 

If the CONFIG.SYS and 
AUTOEXEC.BAT do not exist un¬ 
der the current DOS system, the 
DOS 5.0 Upgrade creates default 
versions for those files. Figure 1 
shows the defaults. 

If the CONFIG.SYS file already ex¬ 
ists on the root directory, the Up¬ 
grade program modifies this file to 
conform to the DOS 5.0 
CONFIG.SYS standards. 

Figure 2 shows a sample 
CONFIG.SYS file. “Old 
CONFIG.SYS” shows the file before 
DOS 5.0. “New CONFIG.SYS” 
shows CONFIG.SYS after the up¬ 
date. Note that the upgrade program 
may not be able to upgrade some 
lines in the file; therefore, those 
lines will be commented (the pro¬ 
gram begins the line with REM). 


Old CONFIG.SYS 

break-on 
fi1es-10 

device=xmaem.sys 

device=xma2ems.sys frame-COOO 

device-ibmcache.sys 

instal1-c:\dos\ifsfunc.exe 

device-c:\net\pcnet.sys 

device-c:\dosl\vdisk.sys 

New CONFIG.SYS 

DEV ICE-C:\D0S\SETVER.EXE 

DEV ICE-C:\DOS\HIMEM.SYS 

DOS-HIGH 

break-on 

fi1es-10 

DEV ICE-C:\DOS\EMM386.EXE frame-COOO 

REM device-ibmcache.sys 

DEV ICE-C:\DOS\SMARTDRV.SYS 

REM install-c:\dos\ifsfunc.exe 

device-c:\net\pcnet.sys 

REM device-c:\dosl\vdisk.sys 

DEV ICE-C:\DOS\RAMDRIVE.SYS 


Figure 2. Comparison of Old and New CONFIG.SYS 
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Old AUTOEXEC.BAT 

PATH-C:\;C:\D0S1; 
ifsfunc.exe 
call autouser.bat 
prompt=$p$g 


New AUTOEXEC.BAT 

PATH=C:\D0S;C:\;C:\D0S1 
REM ifsfunc.exe 
call autouser.bat 
prompt=$p$g 
SET TEMP=C:\D0S 

Note that the path command has 
been updated to include the new 
DOS path. 


Figure 3. Comparison of Old and New 
AUTOEXEC.BAT 

The user should examine the new 
CONFIG.SYS and CONFIG.DAT 
(the old CONFIG.SYS) files and 
should make the necessary changes 
on the commented lines, based on 
the support available for the com¬ 
mands in those lines, to obtain simi¬ 
lar support in DOS 5.0. 

Similarly, if an AUTOEXEC.BAT 
exists in the root directory, the pro¬ 
gram modifies this file to conform to 
DOS 5.0 AUTOEXEC.BAT 
standards. 

Figure 3 shows a sample 
AUTOEXEC.BAT file before and af¬ 
ter upgrading to the DOS 5.0 stand¬ 
ard. “Old AUTOEXEC.BAT’ shows 
the file before DOS 5.0 installation. 
“New AUTOEXEC.BAT” shows the 
file after the update. Note that the 
program may not be able to upgrade 
some lines. In this case, the program 
will comment those lines (the pro¬ 
gram begins the line with REM). 

The user should examine the new 
and old AUTOEXEC.BAT files and 


should make necessary changes to in¬ 
clude these lines based on the sup¬ 
port available for the commands 
specified in the lines under DOS 5.0. 

Upgrading the DOS 4.0 
DOS Shell Menu Files 

If the user has DOS 4.0 .MEU files, 
and if DOS 4.0 is the current DOS 
on the fixed disk, the DOS 5.0 Up¬ 
grade invokes a utility to convert the 
.MEU files to .INI format. 

DOS 4.0 uses a collection of .MEU 
files supporting menus. These are bi¬ 
nary files that form a dependency 
tree. The first file is SHELL.MEU, 


which may contain one or more sub¬ 
menus. Each submenu is stored in a 
separate .MEU file. The utility un¬ 
derstands the hierarchy for the shell 
menu files and converts those files 
into DOSSHELL.INI format. 

The menu system in DOS 5.0 uses a 
file called DOSSHELL.INI. This is 
an ASCII file that contains the infor¬ 
mation about menus and submenus 
for DOS 5.0. (There is one .INI file 
as opposed to various .MEU files.) 
The update program copies a version 
of DOSSHELL.INI to the user’s 
disk. If the user wants to upgrade 
the existing .MEU files, the program 
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uses a utility to transform the .MEU 
files, then append that information 
to the existing DOSSHELL.INI. The 
existing .MEU files are not deleted. 

The DOS 5.0 shell has a few lower 
limits when compared to the DOS 
4.0 shell. For example: 

• The maximum number of prompts 
in the DOS 5.0 shell is 9; it was 
250 in the DOS 4.0 shell. 

• The maximum length of help text 
is 256 bytes; it was 500 bytes. 

• The program item title is 23 char¬ 
acters long; it was 40. 


Refer to Getting Started in the DOS 
5.0 Upgrade for more details. 

Easy Migration 

The DOS 5.0 Upgrade facilitates the 
transition from earlier DOS versions, 
starting with version 2.1, to the lat¬ 
est version of DOS: DOS 5.0. 

The user may want to back up the 
existing system before installing 
DOS 5.0. The program provides a fa¬ 
cility to back up the system files as¬ 
sociated with an earlier version of 
DOS. If the user chooses to reinstall 
the earlier version of DOS at a later 
date, the program knows how to 


copy the files from the backup disk¬ 
ettes and replace the existing boot 
record on the fixed disk. 

The upgrade program updates exist¬ 
ing CONFIG.SYS and 
AUTOEXEC.BAT files. If those 
files do not exist, it brings DOS 5.0 
versions of those files with the rest 
of the system. 

It then copies the DOS 5.0 system 
files to the user’s machine. 

There is one more step: if the user 
has .MEU files (for DOS 4.0 shell 
menus), those files will be converted 
and appended to the .INI file that 
DOS 5.0 uses. 

The purpose of the upgrade program 
is to make it easier for a DOS user 
to migrate to DOS 5.0. 

ABOUT THE A UTHORS 

Pylee Lennil is a staff programmer 
at IBM Entry Systems Division. He 
is presently involved in the 
development of AIX. He previously 
spent several years in PC DOS 
development. Pylee joined IBM in 
1983. He received his B.S. in 
physics from Kerala University in 
India , and an M.S. in computer 
engineering from the University of 
Lowell in Lowell , Massachusetts. 

Clovis L. Tondo is an advisory 
programmer at IBM Entry Systems 
Division , with AIX system design. 

He has an M.S. from Southern 
Illinois University and a Doctorate 
in computer science from Nova 
University. Dr. Tondo is also a 
visiting professor of computer 
science at Nova University , Fort 
Lauderdale , Florida. 



Personal Systems/Issue 4, 1991 















65 


DOS 5.0 

Performance 

Improvements 

Due J. Vianney 
IBM Corporation 
Boca Raton, Florida 

DOS 5.0 provides two major im¬ 
provements over DOS 4.0 that will 
considerably affect the perform¬ 
ance of your applications: reduc¬ 
tion in memory requirements and 
enhancement of fundamental sys¬ 
tem utilities such as expanded 
memory manager (EMM386.SYS), 
disk caching (SMARTDRV.SYS), 
and virtual disk RAMDRIVE 
(RAMDRIVE.SYS). This article dis¬ 
cusses those improvements in¬ 
cluding empirical data collected 
from certain industry-standard 
benchmarks. 

DOS 5.0 achieves its memory reduc¬ 
tion goals by: 

• Reducing the amount of low 640 
KB RAM, that is, conventional 
memory, consumed by DOS. 

• Providing the option of running 
parts of DOS from the High Mem¬ 
ory Area (HMA) as defined in the 
Extended Memory Specification 
(XMS) 2.0. This is available on 
many 286-, 386-, and 486-based 
machines that provide at least 64 
KB of extended memory 

• Relocating buffers into the HMA. 
The HMA is the first 64 KB of 
memory above the 1 MB bound¬ 
ary that marks the end of conven¬ 
tional memory and the beginning 
of extended memory. 

Physical Size Reduction of 
Resident DOS The actual physical 
size of the resident DOS module 
was reduced by 1,378 bytes com¬ 
pared to DOS 4.0. The reduction 


was achieved through the following 

code changes: 

• Replaced support for buffers in 
EMS and hash organization of 
buffers with DOS 3.3 LRU algo¬ 
rithm. This means a return to 
DOS 3.3 buffer management algo¬ 
rithm, in which buffers are organ¬ 
ized as a circular linked list, 
maintained in LRU order, and pro¬ 
vide a pointer to the last buffer 
used. The internal hash organiza¬ 
tion has also been removed, al¬ 
though the secondary caching 
scheme is still supported in DOS 
5.0 (for example, BUFFERS=XY). 

• Removed FASTOPEN extents 
caching. The removal of 
FASTSEEK support from the 
FASTOPEN.EXE program and 
the resident DOS results in a sav¬ 
ings of 1 KB of resident code and 
data. 

• Enabled access to large partitions 
without loading share. In DOS 
5.0, you no longer need to have 
SHARE loaded for 32 MB and 
greater fixed disks. 

• Removed IFS. This includes the 
removal of the undocumented 
IFS, which was added in DOS 4.0. 

• Optimized message retriever and 
other COMMAND.COM code. 
The code optimization in 
COMMAND.COM code has re¬ 
duced the amount of resident 
memory required by about 1,800 
bytes. 

• Added reusable COM- 
MAND.COM code. The resident 
COMMAND.COM code has been 
made reusable. As a result, 
multiple invocations of 
COMMAND.COM share the 
same code, creating a savings of 2 
KB for each invocation after the 
initial COMMAND.COM. 

• Built Upper Memory Block 
(UMB) support into DOS. Pro¬ 


grams and device drivers can be 
loaded high via the device line 
DEVICEHIGH= in CONFIG.SYS 
and LOADHIGH from command 
line or AUTOEXEC.BAT. 

DOS Execution in HMA: The sec¬ 
ond approach used in reducing mem¬ 
ory requirements is to run certain 
DOS functions in HMA, which 
include: 

• Execution of COMMAND.COM 
resident code in the HMA. 
COMMAND.COM was made re¬ 
locatable by separating the code 
and data segments, and by 
making instructions that are not 
relative - jump tables, for exam¬ 
ple - to become relocatable. 

• Internal DOS interface for sharing 
HMA with other DOS device 
drivers and DOS utilities. 

Buffers Relocation in HMA: 

The relocation of the DOS kernel 
and various buffers used by the ker¬ 
nel also contributes significantly to 
the reduction of conventional mem¬ 
ory. DOS 5.0 moves the following 
modules into HMA: 

• DOS Kernel and BIOS - When 
the DOS kernel and BIOS are 
loaded into memory, if the HMA 
is found, DOS and BIOS are relo¬ 
cated to the HMA and initialized 
there. Otherwise, they will be in¬ 
itialized and executed in the con¬ 
ventional memory area. 

• DOS Buffers - In DOS 4.0, the 
number of buffers requested by 
the line BUFFERS= in the 
CONFIG.SYS file is allocated in 
conventional memory. In DOS 
5.0, buffers automatically go into 
the HMA space, if available. 

• Code Page Buffers - These are 
buffers used by DISPLAY.SYS 
and its relocation into the HMA 
can mean an additional 20 KB 
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Conventional Memory 
(in Kbytes) 

DOS 4.0 

DOS 5.0 Low 

DOS 5.0 High 

Interrupt Area 

1.0 KB 

1.0 KB 

1.0 KB 

BIOS Data Area 

0.3 KB 

0.3 KB 

0.3 KB 

System Data 

0.5 KB 

0.5 KB 

0.5 KB 

DOS 

56.0 KB 

54.0 KB 

13.0 KB 

Program Area 

5.8 KB 

4.6 KB 

2.6 KB 

Total 

63.6 KB 

60.4 KB 

14.4 KB 


Figure 1. Memory Used by DOS Functions 


savings for international users 
with two code pages loaded. 

• Part of the HIMEM.SYS - 
HIMEM is an extended memory 
manager whose main function is 
to control and manage the use of 
extended memory by such pro¬ 
grams as disk caching, RAM 
disk, and other extended memory 


programs like Windows 3.0. In 
DOS 5.0, HIMEM.SYS imple¬ 
ments an internal interface with 
DOS that relocates parts of 
HIMEM.SYS to the HMA. 

Effect of Size Reduction: When a 
system is booted and initialized un¬ 
der either DOS 5.0 or 4.0, the Ex¬ 
tended BIOS area occupies 1 KB at 


the high end of the 640 KB bound¬ 
ary, leaving only 639 KB available 
to DOS. Using a one line 
CONFIG.SYS with FILES=20 and 
no AUTOEXEC.BAT file, DOS 4.0 
yields 589,152 bytes of conventional 
memory to applications, while DOS 
5.0 low yields 596,536 bytes and 
DOS 5.0 high yields 636,400 bytes, 
respectively. “DOS 5.0 low” means 
DOS is configured to run in conven¬ 
tional memory (as specified by the 
statement DOS=LOW in 
CONFIG.SYS); “DOS high” means 
DOS is configured to run in the 
HMA (as specified by the statement 
DOS=HIGH in CONFIG.SYS). 

In summary, Figure 1 shows the 
amount of conventional memory 
taken by various DOS functions un¬ 
der DOS 5.0 and DOS 4.0. 

Performance Comparison Between 
DOS Low and DOS High: Given 
the complexity in size reduction and 
relocation of the kernel to the HMA, 
a primary concern is whether the im¬ 
plementation of the memory reduc¬ 
tion strategy impacts performance of 
the base operating system. To meas¬ 
ure the performance impact of DOS 
relocation into HMA, a set of bench¬ 
marks was run on three PS/2 plat¬ 
forms: 8555-061, 8580-311, and 
8595-OJ9. The benchmarks include 
the PC Labs version 5.6 (see Refer¬ 
ence 1 at the end of the article), PC 
Week version 1.1 (see Reference 2), 
and a host of simulated application 
benchmarks from the NSTL (see Ref¬ 
erence 3). The data illustrated in Fig¬ 
ure 2 represents the percent of 
performance difference between 
DOS high and DOS low on each 
hardware platform and the average 
of all three platforms. A negative 
(positive) percent value means DOS 
high is slower (faster) than DOS low 
by that percentage. The result in Fig¬ 
ure 2 suggests that there is no per¬ 
formance difference between DOS 



NC = No Change 

Figure 2. DOS Low and DOS High Performance Comparison 
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low and high in most primitive proc¬ 
essing and I/O operations. However, 
certain application benchmarks, such 
as the NSTL-Foxpro (see Reference 
3), might run faster when DOS is 
loaded in the HMA. In the CPU per¬ 
formance tests, both PC Labs and 
PC Week benchmarks show no 
change (NC) in performance be¬ 
tween DOS low and high. In the I/O 
performance tests, the PC Week 
benchmark shows its database test 
ran 2% faster on the 8580-311 in 
DOS 5.0 high, yet 1% and 2% 
slower on the 8555-061 and 8595- 
OJ9. On the average, these vari¬ 
ations cancel each other out, which 
results in insignificant performance 
change. In the application bench¬ 
marks, the Foxpro benchmark ran 
consistently faster in DOS high, re¬ 
sulting an average of 4% perform¬ 
ance gain overall. 

Performance Comparison Between 
DOS 5.0 and DOS 4.0: Using the 
same measurement approach just de¬ 
scribed, the performance of DOS 5.0 
low and DOS 4.0 is shown in the 
Figure 3. Again, “NC” means the 
performance change is not observ¬ 
able, while a negative (positive) per¬ 
cent value means DOS 5.0 is slower 
(faster) than DOS 4.0 by that per¬ 
centage. While the processor subsys¬ 
tem shows no reaction to either 
DOS, DOS 5.0 certainly improves 
the performance of applications con¬ 
siderably through its I/O perform¬ 
ance improvement as shown by the 
PC Labs benchmark. The PC Labs 
DOS File Access benchmark ran 
25% faster on the 8555-061 and 
8580-311, 9% faster on the 8595- 
OJ9, and on the average, 20% faster 
on DOS 5.0 compared to DOS 4.0. 
The Foxpro benchmark seems to 
benefit most from DOS 5.0, with the 
the average improvement of 9% 
over DOS 4.0. 



NC = No Change 

Figure 3. DOS 4.0 and DOS 5.0 Performance Comparison 


EMM386.EXE 

ENHANCEMENT 

EMM386.EXE is an expanded mem¬ 
ory emulator that uses extended 
memory to simulate expanded mem¬ 
ory to meet the requirements of ap¬ 
plications that use expanded memory 
on 386- and 486-based systems. 

DOS 5.0 EMM386 provides a full 
LIM 4.0 EMS standard, in compli¬ 
ance with VCPI, fully supports the 
Virtual DMA Services specification, 
and searches for and provides upper 
memory blocks (UMBs) via the 
XMS 2.0 Allocate Upper Memory 
Block call. EMM386 must be loaded 
from a device line in CONFIG.SYS. 

Figure 4 shows the performance 
gain of various Excel (see Reference 
3) functions performed under DOS 
5.0 and EMM386.EXE compared to 


DOS 4.0 and XMAEM.SYS. While 
no performance change was ob¬ 
served in transcendental functions, 
charting, and array operations, con¬ 
siderable gain was seen in the last 
four groups of functions: defined 
functions (21%), scaled insert/delete 
(45%), scaled cut/paste (29%), and 
large link and recalc functions (43%). 

RAMDRIVE.SYS 

The virtual disk, known as 
VDISK.SYS in DOS 4.0, is now 
called RAMDRIVE.SYS. It is a util¬ 
ity program that uses system mem¬ 
ory to emulate a temporary disk 
drive. As a result, because the infor¬ 
mation is read from memory (known 
as VDISK or RAMDRIVE) rather 
than from a physical disk, the re¬ 
sponse of your application is very 
fast. However, because the informa- 
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EXCEL 2.1 Functions: 

Percent of Performance Gain 

Transcendental Functions 

NC 

Cut/Paste 

+3% 

Charting (line, bar, area, pie, column, etc.) 

NC 

Insert/Delete (rows, columns) 

+7% 

Financial Functions (ddb, dv, ipmt, nper, 
npv, rate, etc.) 

+3% 

Array Operations (constant and 
parameterized arrays) 

NC 

Database Functions (dmax, dmin, 
dcounta, dproduct, dstdev, etc.) 

+14% 

File Operations (open, close, delete, save) 

+9% 

Defined Functions (solving system of 
equations) 

+21% 

Scaled Insert/Delete 

+45% 

Scaled Cut/Paste 

+29% 


Figure 4. Performance of EXCEL Functions 


tion is stored temporarily in mem¬ 
ory, it will be lost when the system 
is turned off. In DOS 5.0, 
RAMDRIVE uses XMS calls to allo¬ 
cate and manipulate extended mem¬ 
ory. If RAMDRIVE is instructed to 
use extended memory and an XMS 
manager is not present, RAMDRIVE 
won’t install. This makes 
RAMDRIVE compatible with the 
latest standard for using extended 
memory, and removes machine- 
dependent code from RAMDRIVE. 
RAMDRIVE now runs with DOS 
versions up to 5.x. 

In general, it has been observed that 
I/O operations perform better if they 
are running from the ram drive un¬ 
der DOS 5.0 as opposed to running 


Figure 5. Ram Drive Performance Comparison 


from a virtual disk under DOS 4.0. 
Figure 5 shows how the DOS file ac¬ 
cess test in the PC Labs performs un¬ 
der both DOS 5.0 and 4.0. In DOS 
5.0, the test was run from the RAM¬ 
DRIVE created by the device line 
RAMDRIVE.SYS, while in DOS 
4.0, the test was run from the virtual 
disk created by the device line 
VDISK.SYS in the CONFIG.SYS 
file. The value in the table represents 
the percent of performance gain be¬ 
tween DOS 5.0 and DOS 4.0. For ex¬ 
ample, on system 8555-061, based 
on the total time of tests involving 
small record size (Total - Small 
Record Size), the test ran 21% faster 
on DOS 5.0 compared to DOS 4.0. 

In the average, across three different 


platforms, the same test ran 26% 
faster on DOS 5.0. 

SMARTDRV.SYS 

SMARTDRV is a disk caching pro¬ 
gram that can be used to signifi¬ 
cantly reduce the time required to 
read and write data from your hard 
disk. SMARTDRV can use either ex¬ 
tended memory (default) or ex¬ 
panded memory (optional) for its 
disk cache. 

In DOS 5.0, SMARTDRV uses 
XMS calls to allocate and manipu¬ 
late extended memory. As a result, if 
you put the cache in expanded mem¬ 
ory provided by EMM386.EXE, 
your system might not run as fast as 
expected because of the overhead re¬ 
quired by EMM386.EXE to emulate 
expanded memory. There are a few 
enhancements added to the DOS 5.0 
SMARTDRV: 

• It can now buffer all disk I/O via 
its track buffer in conventional 
memory to safeguard against bus 
master DMA hardware that may 
not translate virtual addresses cor¬ 
rectly. This double-buffering 
mechanism may be enabled or dis¬ 
abled on the installation command 
line (/B+ or /B-) or, by default, 
the DMA Services Active bit in 
the BIOS data area is checked and 
double-buffering done when 
DMA Services are active. 

• A quick cache-locking mecha¬ 
nism has been introduced to allow 
Windows to demand page without 
flushing other data from the 
SMARTDRV cache. There are 
now two cache-locking mecha¬ 
nisms. The older mechanism 
locks and unlocks the cache 
though IOCTL Writes. In this 
case, SMARTDRV locks tracks 
currently in the cache. If any 
cache elements are free, they re¬ 
main unlocked and may change 
their contents while the lock is in 
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effect. In the new mechanism, 
whenever the cache is locked, 
SMARTDRV will not replace any 
track currently cached. If any ele¬ 
ments of the cache are free when 
the cache is locked, they too be¬ 
came locked as soon as they are 
used. 

• Caching strategy has been modi¬ 
fied to improve SMARTDRV per¬ 
formance with disk writes. Disk 
writes may update cache contents 
but never cause new tracks to be 
added to the cache. 

• SMARTDRV’s resident track 
buffer is no longer repositioned 
when it falls across a DMA 
boundary. DOS detects this condi¬ 
tion and breaks the DMA into 
pieces without significantly affect¬ 
ing SMARTDRV performance. 

Figure 6 shows the performance 
gain of tests that were running with 
and without SMARTDRV under 
DOS 5.0, on an 8555-061 and an 
8580-311 system. The PC Labs 
benchmark shows the average gain 
of 30% for the DOS File Access 
Test and 51% for the DOS Variable 
Size File Access test. In the Disk- 
tester (see Reference 4) benchmark, 
typical average gain with SMART¬ 
DRV over non-SMARTDRV ranges 
from 31% to 53%. The Disktester 
benchmark consists of a series of 
file operations such as file creation, 
sequential read and write, and ran¬ 
dom read and write performed on 
various file size, record size, and 
number of records. The data pre¬ 
sented in Figure 6 is the average 
result of all tests. 

Conclusion 

DOS 5.0 provides sharp improve¬ 
ments over DOS 4.0. It requires not 



Note: FS = File Size RS = Record Size #RCDS = Number of Records 
Figure 6. Average Result of All Tests 


only less memory but offers more 
functions at better performance. Ap¬ 
plications can now take advantage of 
HIMEM.SYS for a more robust envi¬ 
ronment, relocation of the DOS ker¬ 
nel and various buffers to gain more 
conventional memory, and high per¬ 
formance utilities for a faster time to 
solution. 
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DOS Memory 
Management 
Facilities 

Pylee Lennil 
IBM Corporation 
Boca Raton , Florida 

This article describes the different 
kinds of memory and how DOS 
manages each one. It includes a 
description of the DOS 5.0 mem¬ 
ory management enhancements. 

DOS memory management facilities 
allow applications to access system 
memory on a variety of hardware in 
a well-behaved manner. The basic 
DOS memory management functions 
are: 

• Loading applications into memory 

• Allocating memory blocks to ap¬ 
plications during execution 

• Providing an environment that 
allows applications to access 
memory above 640 KB 

The type of memory management 
support provided by DOS depends 
on the system processor and the 
DOS version used. Intel® 

8086/8088 processors support only 
real mode and have a limited ad¬ 
dress space of 1 MB. The 80286™ 
and higher processors support both 
real and protected modes and can ad¬ 
dress up to 16 or 32 MB. In real 
mode, processors can address only 
up to 1 MB, and in protected mode, 
the processors can address up to 16 
or 32 MB. Protected mode provides 
large memory space to applications 
and is used by operating systems 
like OS/2. Because DOS and its ap¬ 
plications run under real mode, their 
address space is restricted to 1 MB. 
The actual memory space available 
is even less because address space 
between 640 KB and 1 MB is re- 
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Figure 1. System Memory Areas 


served for video buffers, adapters, 
and ROM BIOS. 

System memory is divided into base 
memory, upper memory, high mem¬ 
ory, and extended memory (Figure 
1). Normally, DOS and its applica¬ 
tions run in base memory. Accessing 
memory above 640 KB requires sys¬ 
tems with 80286 or higher proces¬ 
sors, special memory management 
drivers, and DOS 4.0 or 5.0. 

Base Memory Management 

Base memory is located between 0 
and 640 KB. DOS occupies approxi¬ 
mately 50 KB of base memory. The 
remaining base memory is available 
for applications. When an applica¬ 
tion is loaded, it receives all the 
available memory up to 640 KB. 


The application must release the un¬ 
used memory. This way, it can sub¬ 
sequently allocate or free memory 
blocks as needed during execution 
by calling the DOS memory manage¬ 
ment function calls. The caller must 
specify memory size, and then DOS 
returns the segment of the allocated 
memory block. Following are the 
three DOS memory management 
functions. A detailed description of 
these functions is given in the Disk 
Operating System User's Guide and 
Reference (84F9682). 

• Function 48H - allocate memory 
blocks 

• Function 49H - free memory 
blocks 

• Function 4AH - resize memory 
blocks 
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Upper Memory Management 

Upper memory is located between 
640 KB and 1 MB. Normally this 
area is reserved for video buffers, 
adapters, and ROM BIOS. If adapt¬ 
ers are not present, the address 
spaces they would occupy are free. 
Upper memory blocks (UMB) are 
these unused address spaces. Be¬ 
cause no physical memory exists at 
these locations, neither DOS nor ap¬ 
plications can access these blocks di¬ 
rectly. To make use of these blocks, 
you can use an emulator program. 

How do emulators work? The emula¬ 
tor simulates extended memory us¬ 
ing protected mode page tables. The 
emulator gains control every time 
DOS or applications access the up¬ 
per memory block, and it maps the 
address into extended memory. 

UMBs can be accessed by loading 
Microsoft Extended Memory Specifi¬ 
cation (XMS) driver (HIMEM.SYS). 
It provides functions that request 
and release upper memory blocks. 
The UMBs can be used as data buff¬ 
ers, or they can be loaded with pro¬ 
grams. A detailed description of the 
HIMEM.SYS can be found in the 
Microsoft Extended Memory Specifi¬ 
cation (XMS) Version 2.0. 

High Memory Management 

High memory is a 64 KB block of 
memory located between 1024 KB 
and 1088 KB. This memory is 
unique because it can be accessed by 
programs running in real mode, even 
though it exists over 1 MB. The 
high memory area has a unique seg¬ 
ment number FFFFh. Using this seg¬ 
ment, a program can address from 
FFFF:10h to FFFF:FFFFh (64 KB 
minus 16 bytes). Note that high 
memory does not start at 
FFFF:0000h, because the first 16 
bytes are reserved for system use. 
High memory can be used as data 


buffers or it can be loaded with 
programs. 

Unlike other memory areas, high 
memory has several restrictions. Sys¬ 
tems based on 80286 or higher proc¬ 
essors provide high memory support. 
The entire area must be used as a sin¬ 
gle segment with a unique segment 
number FFFFh. The segment cannot 
be shared with other programs. Fi¬ 
nally, it can be accessed only if ad¬ 
dress line A20 is enabled. High 
memory can be accessed using the 
Microsoft XMS driver 
HIMEM.SYS. HIMEM.SYS allows 
programs to access high memory in 
a well-behaved and machine-inde¬ 
pendent manner. It provides func¬ 
tions to enable the line A20, as well 
as to allocate or free the high mem¬ 
ory area. A detailed description of 
the HIMEM.SYS driver can be 
found in the Microsoft XMS 
Version 2.0. 

Extended Memory 
Management 

Extended memory starts at 1088 KB 
and occupies all available memory 


above 1 MB (Figure 1). This mem¬ 
ory area cannot be accessed by pro¬ 
grams running in real mode. 
Accessing extended memory re¬ 
quires extended or expanded mem¬ 
ory drivers running in protect or 
virtual 86 mode supported by 80286 
and higher processors. DOS 5.0 con¬ 
tains both expanded memory man¬ 
ager EMM386.EXE and the 
extended memory manager 
HIMEM.SYS. 

Extended Memory Driver: 

Microsoft XMS driver 
(HIMEM.SYS) provides functions to 
allocate, lock, free and move ex¬ 
tended memory blocks. The allo¬ 
cated extended memory blocks can 
be used only for data storage. A de¬ 
tailed description of HIMEM.SYS 
can be found in the Microsoft XMS 
Version 2.0. 

Expanded Memory Driver: The 

expanded memory driver, 
EMM386.EXE, allows DOS and ap¬ 
plications to access extended mem¬ 
ory blocks (EMB). The expanded 
memory driver creates one or more 
16 KB physical pages in upper mem- 
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Figure 2. Expanded Memory Logical and Physical Pages 


ory or in base memory (Figure 2). It 
also divides extended memory into 
16 KB logical pages. To access ex¬ 
tended memory logical pages, the 
program transfers data into one of 
the physical pages. The expanded 
memory driver maps the extended 
memory logical page into this physi¬ 
cal page. This is like using a physi¬ 
cal page as a window to access 
extended memory logical pages. 

The actual location of the physical 
pages may vary depending on the 
configuration of the hardware. To 
use expanded memory, you must 
load the expanded memory driver us¬ 
ing the device= command in 
CONFIG.SYS. The driver provides 
a set of functions to allocate physi¬ 
cal pages and map logical pages into 
physical pages. Extended memory 


blocks can be used as data buffers or 
they can be loaded with programs. A 
detailed description of expanded 
memory manager functions can be 
found in Lotus/Intel/Microsoft Ex¬ 
panded Memory Specification 
Version 4.0. 

DOS 5.0 Memory 
Management Enhancements 

The major problem facing applica¬ 
tions under DOS is the limited mem¬ 
ory space. In base memory, DOS 
occupies approximately 50 KB. If 
other stay-resident programs or driv¬ 
ers are already loaded, the applica¬ 
tion may have little memory to run. 
DOS 5.0 has implemented the fol¬ 
lowing memory management en¬ 
hancements that provide additional 
memory to applications: 


• DOS 5.0 kernel can be relocated 
to high memory on 80286 or 
higher processor-based systems, 
leaving only a small kernel stub 
in the base memory (Figure 3). 
This releases approximately 30 
KB of memory to applications. 

• DOS 5.0 allows loading device 
drivers and stay-resident pro¬ 
grams into upper memory on 
80386 or higher processor-based 
systems. 

• DOS 5.0 does not require 
SHARE.EXE to be loaded for 
greater than 32 MB hardfile parti¬ 
tion support. 

Relocating DOS kernel, 
stay-resident programs, or device 
drivers requires DOS 5.0 memory 
management drivers HI MEM. SYS 
and EMM386.EXE. HIMEM.SYS 
allocates extended memory, high 
memory, and upper memory area. 
Therefore, HIMEM.SYS must be 
loaded before relocation can be 
done. Relocating DOS kernel needs 
only HIMEM.SYS, whereas 
relocating device drivers and stay- 
resident programs requires both 
HIMEM.SYS and EMM386.EXE. 
Also, DOS 5.0 provides the configu¬ 
ration commands shown in Figure 4 
to relocate DOS drivers and stay-resi 
dent programs. 

The following command loads DOS 
into high memory area. If dos=high 
is not specified, DOS will be kept in 
base memory. 

device = himem.sys 
dos=high 

The EMM386.EXE simulates ex¬ 
panded memory and also allocates 
upper memory blocks. Specifying 
the ram option allows emulation of 
expanded memory, as well as alloca¬ 
tion of upper memory blocks. If no 
emulation is needed, then the noems 
option should be used instead of 
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Figure 3. DOS 5.0 Memory Structure 

ram option. Because EMM386.EXE 
calls HIMEM.SYS to allocate ex¬ 
tended and upper memory blocks, 
HIMEM.SYS must be loaded prior 
to EMM386.EXE. 

The following command emulates 
expanded memory and loads the 


driver mydriver.sys into upper mem¬ 
ory block while keeping DOS in 
base memory: 

device - himem.sys 

device = EMM386.exe ram 

dos=umb 

devicehigh=mydriver.sys 


The following command loads DOS 
into high memory area, the driver 
mydriver.sys, and the stay-resident 
program myprog.com into upper 
memory area. The noems option pre¬ 
vents EMM386.EXE from emulating 
expanded memory. 

device = himem.sys 

device - emm386.exe noems 

dos-high.umb 

devicehigh=mydri ver. sys 

1oadhigh=myprog.com 

To summarize, the DOS memory 
management facilities are available 
based on the type of processors and 
the DOS version used. On 80286 or 
higher processor-based systems, an 
application can access memory 
above 640 KB by using extended or 
expanded memory drivers. DOS 5.0 
provides additional memory to the 
base memory applications by load¬ 
ing DOS into high memory or driv¬ 
ers and stay-resident programs into 
upper memory. 
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Disk Caching 
Under DOS 

Pylee Lennil 
IBM Corporation 
Boca Raton , Florida 

Disk caching is a software 
scheme that improves system per¬ 
formance by saving the recently 
accessed disk data blocks for 
later use. This article presents a 
general overview of disk caching 
and how various disk caching 
schemes are implemented under 
DOS. 

Applications running under DOS 
waste most of their time waiting for 
data from disk, especially if the ap¬ 
plications perform frequent disk ac¬ 
cess. This is because accessing data 
from a disk is much slower than ac¬ 
cessing the same amount of data 
from memory. To access a specific 
disk sector involves physically mov¬ 
ing the read/write head to the right 
track and then waiting until the spe¬ 
cific sector appears under the head. 
These mechanical movements take 
time, affecting the performance of 
the applications. 

The most common technique used 
for solving this hardware problem 
through software is by creating a 
disk caching mechanism. What is 
disk caching? Disk caching involves 
saving blocks of data to and from 
the disk in a memory buffer to re¬ 
duce the number of disk accesses. 
The fewer the disk accesses, the 
better the performance. 

Disk Caching 

Disk caching can be divided into the 
following categories: 

Write-through caching immediately 
writes data blocks to disk. The main 
advantage of this method is that it 


i 



m, 
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maintains file system integrity. Since 
the blocks are not kept in memory 
for delayed writing, the chances of 
losing the data by accidental system 
shut-off are eliminated. On the other 
hand, this method requires frequent 
disk access, which impacts system 
performance. DOS uses write- 
through caching only if specifically 
requested through DOS Extended 
Open function call. 

Write-back disk caching is based on 
a delayed disk write. A cache buffer 
keeps data blocks to be written to a 
specific track on the disk. Several 
disk writes to the same track are per¬ 
formed at one time, avoiding re¬ 
peated writes to the same track. This 
is nothing more than flushing the 
cache buffers periodically to the ap¬ 
propriate track on the disk. The de¬ 
layed write has an inherent problem. 
If the system is turned off before the 
data is written to the tracks, the sys¬ 
tem fails to update the file system in¬ 
formation, causing file system 
corruption. DOS normally writes the 
data blocks to disk only when the 
file is closed. 



Read-through disk caching reads the 
requested data blocks into an applica¬ 
tion buffer. It also keeps a copy of 
the blocks in system cache buffers 
for future use. The assumption here 
is that the application will most 
likely request the same sectors in 
subsequent reads. DOS utilizes this 
method during all disk reads by 
keeping a copy of the most recently 
read disk sectors in a group of sys¬ 
tem buffers. Read-through caching is 
also used by disk caching programs 
like IBMCACHE and SMARTDRV. 

Read-ahead disk caching involves 
reading a few additional sectors im¬ 
mediately following the requested 
sector into a cache buffer. These sec¬ 
tors may be beneficial in the case of 
a sequential disk access. In DOS, 
this method is implemented as look¬ 
ahead buffers supported by the 
BUFFERS=m,n command in 
CONFIG.SYS. 

These disk caching methods are 
used in DOS either internal or exter¬ 
nal to DOS. The internal disk cach¬ 
ing schemes are built into DOS as 
system buffers, look-ahead buffers. 
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and cluster and disk directory infor¬ 
mation cache buffers. The external 
caching is enabled by loading cach¬ 
ing programs like IBMCACHE, 
SMARTDRV, or any other similar 
caching program. These programs 
are loaded as DOS drivers or stay 
resident programs. 

DOS Internal Disk Caching 

DOS internal disk caching is de¬ 
signed based on the workings of the 
DOS file allocation table, disk direc¬ 
tory, and the general operation of 
the disk. The internal disk caching 
methods are: 

System Buffers: DOS system buff¬ 
ers provide a basic disk caching 
mechanism that uses the read- 
through caching method. System 
buffers are a group of circular buff¬ 
ers maintained by DOS for caching 
the data flowing between the disk 
and the application. As shown in 
Figure 1, each buffer consists of a 
buffer header and a 512-byte buffer 
data area. Each buffer can hold one 
sector. The buffer header contains in¬ 
formation such as the link address to 
the next buffer, the sector number as¬ 
sociated with the buffer, and a flag 
indicating if the buffer is free. 

How do system buffers work? To 
understand buffers, consider the fol¬ 
lowing steps required for accessing a 
file: 

1. Read the file’s path information 
from the disk directory 

2. Read the file’s sector location in¬ 
formation from the file allocation 
table 

3. Read the file data sectors from the 
disk 

During these steps, the sectors read 
are kept in the system buffers. Dur¬ 
ing subsequent disk read requests. 


DOS checks the system buffers to 
see if the required sectors are avail¬ 
able in the cache. If they are avail¬ 
able, further disk reads are avoided, 
thereby improving performance. The 
number of system buffers is speci¬ 
fied by the “m” parameter in the 
BUFFERS=m,n command. Once the 
buffers are full, buffers holding the 
least recently used sectors are freed 
to make room for newly read disk 
sectors. 

System buffers provide better per¬ 
formance during random disk reads. 
Specifying a large number of system 
buffers may further enhance random 
disk reads, but it may degrade the 
performance of sequential disk 
reads. This is because large buffers 
require an extensive search through 
the buffers for sectors that are un¬ 
likely to be found under sequential 
disk reads. Also, a large number of 
buffers will occupy large portions of 
base memory, leaving less memory 
for applications. 

Look-ahead Buffers: In DOS, cach¬ 
ing the adjacent sectors is done us¬ 
ing a group of look-ahead buffers. 
These buffers hold a few sectors 
ahead of the requested sectors, with 
the assumption that these sectors 
will be requested during a sequential 
file access. The look-ahead 
buffers are enabled using the 
BUFFERS=m,n command in the 
CONFIG.SYS file. Here “n” speci¬ 
fies the number of look-ahead buff¬ 
ers. For instance if n=2, then when 
the application requests DOS to read 
sector 50, DOS reads sectors 51 and 
52 in addition to sector 50, and 
keeps these additional sectors in the 
look-ahead buffers. Look-ahead buff¬ 
ers provide best performance during 
sequential disk reads and provide lit¬ 
tle or no improvements under ran¬ 
dom disk reads. 


File Allocation and Path 
Information Caching: DOS disk 
caching is also designed based on 
the workings of the DOS disk direc¬ 
tory and file allocation table. Per¬ 
formance will be improved if 
portions of the file allocation table 
or disk directory are kept in main 
memory for subsequent use. This 
caching method is implemented in 
FASTOPEN under DOS. How does 
FASTOPEN work? FASTOPEN is a 
stay-resident program that caches 
the file sector location information 
and the file path information of the 
most recently accessed files. To see 
how FASTOPEN works, consider 
the following steps DOS performs 
during a file access: 

1. Reads the file’s path information 
from the disk directory 

2. Reads the file’s sector location in¬ 
formation from the file allocation 
table 



Figure 1. DOS System Buffers 


Personal Systems/Issue 4, 1991 























76 


Page Tag Buffers 


Page Buffers 



Page - 1 

(2 to 8 Sectors/Page) 


Page - 2 


Figure 2. Page and Page Tag Buffers 


During file access, FASTOPEN 
keeps both the path and sector loca¬ 
tions of files in cache buffers. This 
information can be reused for sub¬ 
sequent access of the same files. 

This effectively reduces steps 1 and 
2, which, in turn, improves perform¬ 
ance. FASTOPEN is enabled using 
the command FASTOPEN C: (n,m). 
Here “n” is the number of file path 
buffers, and “m” is the number of 
sector information buffers. If the 
buffers are full, then space is created 
by deleting the least recently used 
file information from the cache buff¬ 
ers. The “m” and “n” values in the 
FASTOPEN command must be 
specified based on the way files and 
directories exist on the disk. A large 
“m” value should be used if the file 
path consists of many levels of sub¬ 
directories and a large “n” value if 
files are highly fragmented. 

Performance improvement under 
FASTOPEN depends mainly on the 
behavior of the application. 
FASTOPEN improves performance 
for applications accessing frag¬ 
mented files. It also improves per¬ 
formance for applications that 
require repeated file and directory 
access. 


DOS External Disk Caching 

DOS external disk caching is pro¬ 
vided by cache programs like 
IBMCACHE and SMARTDRV. 
These programs can be loaded as 
DOS device drivers. They maintain 
their own cache buffers either in 
base memory, extended memory, or 
expanded memory. During disk ac¬ 
cess, the program takes control and 
reads the sectors transferred between 
the disk and the application into 
cache buffers for future use. Unlike 
system buffers, which provide opti¬ 
mal performance under random disk 
access, these programs improve per¬ 
formance for both sequential and ran¬ 
dom disk-access environments. 

The cache buffer consists of two 
areas as shown in Figure 2. The 
large area contains pages and the 
small areas contain page tags. Each 
page has a fixed size that holds two 
to eight disk sectors. Each tag identi¬ 
fies a page in the page buffer. The 
tag contains information on the sec¬ 
tors held in each page. During disk 
I/O, multiple pages are read into the 
cache buffer, depending on the size 
of the data block requested. Even if 
only one sector in a page is re¬ 
quested, the entire page is read into 


the buffer. This works like the look¬ 
ahead buffer method. Additional sec¬ 
tors read are the most likely to be 
used by sequential reads. 

The major advantage of DOS exter¬ 
nal disk caching programs is that 
they support both read-through and 
read-ahead caching methods. This 
improves the performance of sequen¬ 
tial as well as random disk reads. Ex¬ 
ternal caching allows users to 
specify a large number of buffers ca¬ 
pable of loading them into extended 
or expanded memory. Because they 
are device drivers or resident pro¬ 
grams, they can be loaded only if 
needed. 

Summary 

System buffers improve perform¬ 
ance for random disk I/O. Look¬ 
ahead buffers improve performance 
under sequential disk I/O. 
FASTOPEN improves performance 
for accessing fragmented files, and 
in the case of repeated access of 
files and directory path names. Exter¬ 
nal disk caching programs improve 
performance for both sequential and 
random disk I/O. 
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NetWare 

Client-Server 

Interaction 

Paul Turner 
Novell Inc. 

Provo , Utah 

On a NetWare LAN, several soft¬ 
ware components work together 
to enable communication between 
the workstation client and the file 
server. The NetWare workstation 
shell (NETx.COM) manages the 
connection with the server, while 
IPX.COM forms the communica¬ 
tions link with the network hard¬ 
ware. This article presents a 
behind-the-scenes look at how 
these pieces use NetWare’s com¬ 
munications and routing protocols 
to establish and maintain the vital 
client-server connection. 


The NetWare shell facilitates client- 
server communications for DOS- 
based workstations. In a typical 
client-server interaction, one station 
(the client) requests services from an¬ 
other station (the server). Through 
the shell, DOS-based applications 
can request file services (such as 
writing to and reading from files) 
from NetWare file servers. At the 
workstation, the shell, the user appli¬ 
cation, and the user together act as 
the client requesting file services; 
the NetWare file server acts as the 
server providing file services. 

The shell, then, is the liaison be¬ 
tween the client (the user applica¬ 
tion) and the server. The shell 
performs the tasks necessary to re¬ 
quest file services from a NetWare 
file server: for example, establishing 
a connection with the file server. 


maintaining the connection, and ter¬ 
minating the connection. 

The NetWare shell is a terminate- 
and-stay-resident (TSR) program 
called NETx.COM (where x de¬ 
pends on the version of DOS being 
run). NETx.COM is loaded into a 
NetWare workstation’s memory 
when the workstation is booted. Be¬ 
fore you load the shell, however, 
you must load another TSR called 
IPX.COM. 

IPX.COM 

Novell’s Internetwork Packet Ex¬ 
change (IPX) protocol serves as the 
communications link with the net¬ 
work interface card (NIC) installed 
in the workstation. At installation, a 
customized version of IPX.COM is 
generated for each workstation by 
linking in a driver written specifi- 
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cally for the NIC that resides in that 
workstation. Once IPX.COM is 
loaded, any workstation program, in¬ 
cluding the shell, can communicate 
on the network through NetWare’s 
IPX protocol. 

Recently, as part of its Open Data- 
Link Interface (ODI) specification, 
Novell began distributing a new set 
of modules that provide greater flexi¬ 
bility than IPX.COM. Under ODI, 
an intermediate link support layer 
(LSL) separates the NIC driver from 
IPX and other protocol stacks. This 
separation allows NIC drivers to be 
independent of IPX, thereby elimi¬ 
nating the need to generate a custom 
IPX.COM file for each workstation. 
The LSL also allows multiple proto¬ 
col stacks to communicate over the 
same NIC simultaneously. 

To bring up a workstation using 
ODI, the link support layer 
(LSL.COM) must be loaded first, fol¬ 
lowed by a NIC driver (such 
as TOKEN.COM or NE2000.C0M). 
Finally, the protocol stacks (IPX, 
TCP/IP, and so on) are loaded and 
bound to a NIC driver through the 
LSL. 

Together, the ODI NIC driver, the 
LSL, and the IPX protocol stack pro¬ 
vide the same functionality as 
IPX.COM. All references to 
“IPX.COM” in this article apply 
also to the ODI implementation of 
IPX. 

In addition to interfacing with the 
NIC, IPX.COM performs several 
communication-related functions. 

For example, it manages the IPX 
sockets used with the workstation. 
The shell and other applications ac¬ 
cess IPX.COM to open and close 
IPX sockets. When the workstation 
receives an IPX packet, IPX.COM 
checks which socket the packet is ad¬ 


dressed to and passes the packet to 
the program having that socket open. 

IPX.COM is also responsible for de¬ 
termining the address of the network 
segment to which the workstation is 
physically connected. The worksta¬ 
tion’s network number, along with 
its node address, make up the work¬ 
station’s full internetwork address. 

IPX can determine the workstation’s 
network number in one of two ways. 
In the first method, IPX.COM 
watches for any routing information 
protocol (RIP) broadcasts sent on 
the network. Because RIP packets 
are not forwarded to other network 
segments, IPX knows that this type 
of broadcast originated on the seg¬ 
ment to which the workstation is di¬ 
rectly connected. To determine the 
workstation’s network number, IPX 
simply reads the source network ad¬ 
dress contained in the IPX header of 
a RIP broadcast. 



The shell (NETx.COM) 
acts as the interface 
between user applications 
and NetWare file servers. 


IPX uses an alternate method if the 
shell requests a route to a network 
number before IPX can determine 
the workstation’s network number 
from a RIP broadcast. In this case, 
IPX broadcasts a Get Local Target 
packet, which requests the fastest 
route to the destination network num¬ 
ber requested by the shell. Upon re¬ 
ceiving a response, IPX.COM 
checks the source network number 
in the IPX header of the response 
packet. This source network number 


(the network number of the router 
that responded to the Get Local Tar¬ 
get request) is the workstation’s net¬ 
work number. 

The NetWare Shell 

The shell (NETx.COM) acts as the 
interface between user applications 
and NetWare file servers. As user ap¬ 
plications make requests, the shell 
determines whether the requests 
should be handled locally by DOS 
or sent to a server on the network. If 
the shell determines that the request 
should be sent to a network server, 
the shell formulates a request 
packet, hands it to IPX.COM for 
transmission, and waits for a 
response. 

Prior to submitting any requests to a 
server, the shell must establish a con¬ 
nection with that server. The shell 
can establish a connection to a serv¬ 
er in two ways. When the shell is 
first loaded at the workstation, it 
logically attaches to the first server 
that responds (usually the server 
nearest to the workstation). The 
LOGIN and ATTACH command 
line utilities, when executed, also 
establish a server connection. 

To establish a connection, the work¬ 
station and the server must exchange 
several packets. One of these pack¬ 
ets requests that a connection num¬ 
ber be assigned to the shell. Another 
proposes the maximum packet size 
that will be allowed in the interac¬ 
tion between the file server and the 
shell. Before sending these initial 
packets, the shell needs the server’s 
address and a route to that address. 

Getting a Server’s Address 

To acquire a server’s address, the 
shell can use the service advertising 
protocol (SAP) to broadcast a re¬ 
quest for the address of the nearest 
server - a Get Nearest Server re- 
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Give Nearest Server Response 


Get Nearest Server (Local Broadcast) 



FS1/Address/1 Hop 


FS2 



|Er 



FS2/Address/l Hop 


Figure 1. Getting the Address of the Nearest File Server 


quest. All routers on the worksta¬ 
tion’s network segment having infor¬ 
mation about the nearest server 
respond to the Get Nearest Server re¬ 
quest. Each response contains the 
nearest server’s name, its full inter¬ 
network address, and the number of 
hops required to reach the server 
(Figure 1). 

When first loaded at a workstation, 
the shell issues a Get Nearest Server 
request to establish an initial connec¬ 
tion to a file server. If the shell loses 
its connections with all file servers, 
it resorts to the Get Nearest Server 
request method to re-establish a 
server connection. 


A second method the shell uses to 
get a server’s address is to use the 
NetWare core protocol (NCF) to ac¬ 
cess a file server’s bindery. The 
bindery is a database within 
NetWare file servers that contains in¬ 
formation about many network enti¬ 
ties, including users, groups, and 
servers. 

Because the shell must already have 
a server connection before it can ac¬ 
cess the server’s bindery, the shell 
can use this method only after it has 
established an initial connection to a 
file server. The LOGIN and 
ATTACH utilities use this method, 
as does the new “preferred server” 


shell (version 3.01 or later). These 
programs allow the user to specify a 
specific file server name, then use 
that name to scan the bindery for the 
server’s address. 

Getting a Route to a Server 

Once the shell has the server’s ad¬ 
dress, it needs a route to get to that 
address. The shell uses this route for 
all subsequent communications with 
the server for the duration of the 
connection. 

The shell submits a Get Local Tar¬ 
get request to IPX.COM to obtain a 
route. IPX first compares the net- 
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work number of the desired server 
to the workstation’s network num¬ 
ber. If these two numbers are the 
same, IPX tells the shell to send re¬ 
quests directly to the server (without 
going through an intermediate 
router). 

If the network number submitted by 
the shell and the workstation’s net¬ 
work number are not the same, IPX 
broadcasts a RIP request for the fast¬ 
est route to the submitted network 
number. Whichever router on the 
workstation’s network segment has 
the shortest route to the network re¬ 
sponds to the request. More than one 
router might respond if several rout¬ 


ers have a route equal to the shortest 
route. IPX accepts only the first 
router’s response and discards all 
others. 

IPX then returns to the shell the 
node address of the first router that 
responded. The shell places the node 
address of this router in the MAC 
header of a Create Connection re¬ 
quest packet. It addresses the IPX 
header of the request packet to the 
file server to which it wants to con¬ 
nect. With the packet addressed in 
this fashion, the router receives the 
packet first, checks the IPX destina¬ 
tion address, and forwards the 
packet to the network number on 


which the file server resides 
(Figure 2). 

Establishing an Initial 
Connection 

To establish its connection to a file 
server, the shell uses a combination 
of the SAP, the RIP, and the NCP. 
The sequence followed is slightly 
different for the preferred server 
shell than it is for previous shell 
versions. 

Figure 3 shows the steps taken by 
shells prior to version 3.01 to con¬ 
nect with a file server. The first col¬ 
umn represents the call or packet 
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Call 

Source 

Destination 

Protocol 

1. Get Nearest Server 

Client 

Broadcast 

SAP 

2. Give Nearest Server 

Router 

Client 

SAP 

3. Get Local Target 

Client 

Broadcast 

RIP 

4. Give Local Target 

Router 

Client 

RIP 

5. Create Connection 

Client 

File Server 

NCP 

6. Request Processed; Connection # Assigned 

File Server 

Client 

NCP 

7. Propose Packet Size 

Client 

File Server 

NCP 

8. Return Maximum Packet Size 

File Server 

Client 

NCP 


Figure 3. Initial Connection Sequence for the NetWare Shell (Prior to Version 3.01) 


sent. The second column lists the 
source, or sender, of the packet. The 
third column lists the addressee of 
the packet. The final column indi¬ 
cates the protocol used for handling 
the packet. 

We have already seen how the first 
four steps work. In steps 1 and 2, 
the shell obtains the address of the 
nearest server. Step 3 is IPX.COM’s 
request for the fastest route to the ad¬ 
dress that the shell received in step 
2. Step 4 is the response by all rout¬ 
ers with the shortest route to that 
segment. 

Steps 5 through 8 show the packets 
exchanged between the shell and the 
server to establish the initial connec¬ 
tion. Once this connection is made, 
the shell moves to the background 
(terminates-and-stays-resident) and 
returns the DOS prompt to the user. 
The user can then execute 
LOGIN.EXE to log in to the con¬ 
nected server or to another server. 

The Preferred Server Shell 

The preferred server shell (version 
3.01 and above) features several ad¬ 
ditional functions not offered by 
older versions of the shell. As its 
name implies, the preferred server 
shell allows users to specify, either 
at the command line, or in the 
SHELL.CFG or NET.CFG file, the 
server to which they would like to 
connect. Whether or not a preferred 
server is specified, the preferred serv¬ 
er shell goes through the same initial 
eight steps as the old shells. 

During the initial eight steps, the 
shell might connect to a server other 
than the preferred server. If so, the 
shell performs additional steps to es¬ 
tablish connection with the preferred 
server (Figure 4). 


For example, if the workstation in 
Figure 1 initially connects to FS1 
and the user specified FS3 as the pre¬ 
ferred server, the shell will follow a 
sequence similar to that shown in 
Figure 4. In step 9, the preferred 
server shell uses the bindery method 
of acquiring the server’s address. 

Steps 11 and 12 of this preferred 
server sequence are not always re¬ 


quired. If the preferred server re¬ 
sides on the same network segment 
as the workstation, the shell skips 
these two steps and sends the Create 
Connection request directly to the 
server. The shell destroys the connec¬ 
tion with the initial server once it 
has successfully connected to the 
preferred server. 


Call 

Source 

Destination 

Protocol 

1. Get Nearest Server 

Client 

Broadcast 

SAP 

2. Give Nearest Server 

Router 

Client 

SAP 

3. Get Local Target 

Client 

Broadcast 

RIP 

4. Give Local Target 

Router 

Client 

RIP 

5. Create Connection 

Client 

FS1 

NCP 

6. Request Processed; Connection # Assigned 

FS1 

Client 

NCP 

7. Propose Packet Size 

Client 

FS1 

NCP 

8. Return Maximum Packet Size 

FS1 

Client 

NCP 

9. Query Bindery for Preferred Server 

Client 

FS1 

NCP 

10. Address of Preferred Server 

FS1 

Client 

NCP 

11. Get Local Target 

Client 

Broadcast 

RIP 

12. Give Local Target 

FSl’s 

Router 

Client 

RIP 

13. Create Connection 

Client 

FS3 

NCP 

14. Request Processed; Connection # Assigned 

FS3 

Client 

NCP 

15. Propose Packet Size 

Client 

FS3 

NCP 

16. Return Maximum Packet Size 

FS3 

Client 

NCP 

17. Destroy Service Connection 

Client 

FS1 

NCP 


Figure 4. Connection Sequence for the Preferred Server Shell 
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Call 

Source 

Destination 

Protocol 

1. Query Bindery for Preferred Server 

Client 

FS1 

NCP 

2. Address of Preferred Server 

FS1 

Client 

NCP 

3. Get Local Target 

Client 

Broadcast 

RIP 

4. Give Local Target 

FSl’s 

Router 

Client 

RIP 

5. Create Connection 

Client 

FS3 

NCP 

6. Request Processed; Connection # Assigned 

FS3 

Client 

NCP 

7. Propose Packet Size 

Client 

FS3 

NCP 

8. Return Maximum Packet Size 

FS3 

Client 

NCP 

9. Destroy Service Connection 

Client 

FS1 

NCP 


Figure 5. Additional Steps Performed by LOGIN.EXE 


Another major difference between 
the old shell and the preferred server 
shell involves the receipt of Give 
Nearest Server responses. Older 
shells accept the first Give Nearest 
Server response they receive and ig¬ 
nore all subsequent responses. Pre¬ 
ferred server shells also accept the 
first response, but save the next four 
Give Nearest Server responses in 
case a connection cannot be made to 
the first server. 

Servers respond to Get Nearest Serv¬ 
er requests even if they have no free 
connections. Consequently, older 
shells fail to establish a connection 
(steps 5 and 6 of Figure 3) if the 
first Give Nearest Server response re¬ 
ceived is from a server with no free 
connections. The preferred server 
shells, on the other hand, can refer 
to the next saved Give Nearest Serv¬ 


er response if the current attempt to 
establish a connection fails. 

LOGIN.EXE 

Users can run LOGIN.EXE any time 
after the shell has connected to a 
NetWare file server. LOGIN submits 
the user’s name and password to the 
file server for verification. It also es¬ 
tablishes a new server connection if 
the user specifies a file server name 
in the LOGIN command. 

If the server specified at the com¬ 
mand line is not the one the shell is 
already connected to, LOGIN fol¬ 
lows the steps outlined in Figure 5. 
Once these steps are completed, 
LOGIN verifies the username and 
password. If the server specified at 
the command line is located on the 
same segment as the workstation, 
steps 3 and 4 are not necessary. 


ATTACH.EXE uses the same 
sequence as that described for 
LOGIN.EXE when establishing 
connections to a file server. 

Connection Management 

Communication between any two 
workstations requires a certain 
amount of responsibility on both 
sides to ensure that no information is 
lost. In the NetWare environment, 
NICs maintain error checking at the 
bit level. File servers and worksta¬ 
tion shells handle at the packet and 
session level. 

It is a common misconception that 
SPX is used for packet-level error 
checking between workstations and 
servers; however, SPX is used only 
for peer-to-peer interaction. It is actu¬ 
ally the NCP that governs the way 
connection control information is ex¬ 
changed. Every NCP packet a client 
submits to a NetWare file server 
must contain a connection number 
and a sequence number. The connec¬ 
tion number assigned to the client 
when the file server connection is es¬ 
tablished. The sequence number 
identifies each packet so that both 
the server and the shell can tell if a 
packet gets lost. 

The Shell’s Connection Table 

NETx.COM (the shell) can support 
up to eight server connections con¬ 
currently. NETx.COM maintains a 
connection table to track these con¬ 
nections (Figure 6). 

Within each entry in this table, the 
shell stores the name and full inter¬ 
network address of the server to 
which it is connected. If the shell is 
forwarding packets through an inter¬ 
mediate router to the server, the 
node address of that router will be 
stored in the Router’s Node Address 
field. The shell’s connection number 
and packet sequence number are 


Server’s 
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Figure 6. Portion of the Shell’s Connection Table 
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Connection 
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Sequence 
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Watchdog 

Count 

Watchdog 

Timer 

NIC 

Number 

Intermediate 
Router’s Address 





























Figure 7. A Portion of the NetWare File Server’s Connection Table 


also kept in the table. The sequence 
number is set to zero when the con¬ 
nection is first established and incre¬ 
mented with each new request sent. 

The shell’s connection table also 
maintains two timeouts. Max Time 
Out is the maximum time the shell 
will wait for a response from the 
server before resending a request 
packet. This timeout is based on an 
estimate of the time (in ticks) 
needed to deliver a packet to the 
server. The router provides this time 
estimate in its Give Immediate Ad¬ 
dress response. (If the workstation 
and the server are on the same seg¬ 
ment, this value is set to one tick.) 

To set its maximum timeout for com¬ 
munications with a server, the shell 
multiplies this estimate by 16 and 
adds 10 ticks to the result. 

The Receive Timeout is a dynamic 
timeout originally set to four times 
the time estimate received in the 
Give Local Target response plus 10 
ticks. 

Receive Timeout = 4t + 10 

Once initially set, the receive time¬ 
out adjusts up or down to adapt to 
changing network conditions. If the 
shell issues a request to a server and 
does not receive a response within 
its current receive timeout, the re¬ 
ceive timeout is increased by one 
and a half times its original value. 

New Receive Timeout = 

1.5 (current Receive Timeout) 


It remains at this new value for all 
subsequent retries of the current re¬ 
quest and on first try of the next re¬ 
quest. If the next request requires a 
retry, the receive timeout is in¬ 
creased again. The shell continues to 
increase the receive timeout until it 
reaches the maximum timeout. 

Each time the shell does not have to 
issue a retry to a request, it de¬ 
creases the receive timeout. To deter¬ 
mine how much to decrease the 
receive timeout, the shell takes the 
time to receive a response to the last 
request (that didn’t require a retry), 
multiplies that value by two, and 
adds 10 ticks. The shell sets the new 
receive timeout to the average of 
this calculated value and the current 
receive timeout. 

New Receive Timeout = 

[2(Time to receive response) + 10 
+ Current Receive Timeout]/2 

The number of times the shell will 
resend a request to a server is deter¬ 
mined by the IPX Retry Count. If 
this count is exceeded, the shell 
gives up and presents the user with a 
“Network error on server xxxxx. Er¬ 
ror xxxxx from network. Abort , Re¬ 
try?” message. All drivers have a 
default for this retry count. This de¬ 
fault differs from driver to driver but 
is generally between 20 and 40. The 
SHELL.CFG file’s “IPX RETRY 
COUNT = xx” option allows the de¬ 
fault IPX retry count to be modified; 
however, some drivers ignore this en¬ 


try in the configuration file and 
leave the retry count at their default. 

The File Server Connection 
Table 

The file server connection table 
shown in part in Figure 7 allows the 
server to keep information about 
each of the clients it is servicing. 

The server uses the address fields 
for addressing response packets and 
for security purposes. When a 
packet arrives with a service request, 
it contains the connection number as¬ 
signed to the sender. The server 
matches the packet’s IPX source ad¬ 
dress (network, node, socket) with 
the address registered for that con¬ 
nection number. If the addresses 
don’t match, the server regards the 
request as a security breach. 

The NIC Number and Intermediate 
Router’s Address fields are used for 
sending responses to clients. As a re¬ 
quest packet is received, the server 
places the number of the NIC the re¬ 
quest came in on in the NIC Num¬ 
ber field. This number would be A, 

B, C, or D for NetWare version 
2.15c and earlier, or the NIC’s net¬ 
work number for NetWare versions 
3.0 and higher. 

If the packet was forwarded through 
one or more routers, the server 
stores the node address of the last 
router in the Intermediate Router’s 
Address field. This saves the server 
from having to find a route to the cli¬ 
ent when it is ready to send a re¬ 
sponse. The server gets the node 
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address of the first router from the 
Intermediate Router’s Address field 
and places it in the MAC header des¬ 
tination address field. It then sends 
the packet through the NIC specified 
in the NIC Number field. Of course, 
it first places both the client’s and 
its own full network address in the 
destination and source address fields 
of the IPX header, respectively. 

The Sequence Number field is used 
for packet-level error checking. The 
Watchdog Count and Timer fields 
are used by the watchdog process, 
which is discussed later. 


File servers also maintain a 100-byte 
reply buffer for each of their connec¬ 
tions. If a response to a client is less 
than 100 bytes, the server places a 
copy of the response in the buffer 
corresponding to that connection. 
That way, if the client does not re¬ 
ceive the response and resends the 
request, the server will not have to 
reprocess it. 

Packet-Level Error Checking 

The bit-level error checking pro¬ 
vided by network adapters detects 
the corruption of individual bits 
within a packet. When an adapter 
finds that part of a received packet 


is corrupted, it discards the entire 
packet. Because of the driver’s sim¬ 
ple design, it contains no mechanism 
to request that the packet be resent 
or to inform the upper-layer proc¬ 
esses and applications that an error 
occurred. Therefore, the upper-level 
sending process (the shell or file 
server) must determine when a 
packet has not reached its intended 
destination. 

In the NetWare environment, this 
packet-level error checking is the re¬ 
sponsibility of the shell. The NCP 
permits a workstation shell to submit 
only one server request at a time. 
Furthermore, the server’s response 
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Workstation 


Second Identical Service Request 



File Server 



Figure 9. Response Lost in Transit to Shell 


must fit in a single packet - the shell 
should never request more than a 
packet’s worth of information. To 
guarantee that no packets have been 
lost, the shell has only to make sure 
it receives a completed response to 
each of its requests. 


Each workstation request contains a 
sequence number within the NCP 
header. The server’s response is 
labeled with the same sequence num¬ 
ber. Ultimately, the shell is responsi¬ 
ble for getting a completed response 
for each service requests it submits. 

If the shell does not receive a re¬ 


sponse to its most recent request 
within the specified receive timeout. 
The shell continues to resubmit the 
request until it either receives a 
response or exceeds its IPX Retry 
count. 
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No response 
from server 
within shell’s 
time-out 



,//L 


Workstation 



Service Request 


Second Identical Service Request 



File Server 



Workstation 


File Server 



Workstation 


Busy Now but Have Received Your 
Request and Will Respond 



File Server 



Workstation File Server 


Figure 10. File Server is Busy 


Three conditions can cause the shell 
to timeout while waiting for a re¬ 
sponse from a server. Figure 8 illus¬ 
trates a case in which the request is 
lost in transit to the server. The 
shell’s timeout eventually expires, 
upon which the shell resends the 
same request. The server receives 


the duplicate request, processes it, 
and sends back the response. 

In Figure 9, the request is received 
by the server, but the response is 
lost in transit to the workstation. 
Once the workstation’s timeout 
reaches its limit, the shell sends a 


second, identical request to the 
server. 

When a server receives any request, 
it checks the request’s sequence 
number to see that it is one greater 
than the sequence number registered 
in the server’s connection table. If it 
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is, the server increments that number 
and processes the request as usual. 
However, if the two sequence num¬ 
bers are the same, the server deter¬ 
mines that the client, for whatever 
reason, is resubmitting its last 
request. 

In some cases, the server might have 
a copy of the last response in its 100- 
byte response buffer for that connec¬ 
tion. When a server sends a response 
less than 100 bytes long, it places a 
copy in that client's buffer - that is, 
the buffer corresponding to that cli¬ 
ent’s connection number. Since a 
large percentage of responses are 
smaller than 100 bytes, there is a 
good chance that a server will have 
a copy of the response when re¬ 
quests are resubmitted by clients. 
(This type of response increments 
the Duplicate Replies Sent counter 
on the the FCONSOLE Statistics- 
LAN I/O Statistics screen.) 

For requests larger than 100 bytes, 
the server must reprocess the request 
before sending the response. (This 
type of response increments the Re- 
executed Requests counter in 
FCONSOLE.) 

The response might still be in transit 
to the workstation when the shell 
times out and resubmits the request 
(that is, the shell receives the com¬ 
pleted response after resending the 
request). In this case, the server will 
send another response, but the shell 
will ignore it. 

Sometimes the server is too busy to 
respond within the shell’s timeout 
period (Figure 10). As usual, the 
shell resends the request. When the 
server receives this second request, 
it sends a reply stating that the in¬ 
itial request was received success¬ 
fully, but the processing is not yet 
completed. (This intermediate re¬ 
sponse increments the Positive Ac- 


Time 0 — 


(minutes) ^ 

1 3 - 


1 4 - 

5 - 

— Watchdog packet sent 

6 - 

— Watchdog packet sent 

7 - 

— Watchdog packet sent 

8 - 

— Watchdog packet sent 

9 - 

— Watchdog packet sent 

10 - 

— Watchdog packet sent 

11 - 

— Watchdog packet sent 

12 - 

— Watchdog packet sent 

13 - 

— Watchdog packet sent 

14 - 

— Watchdog packet sent 

15 - 1 

Watchdog packet sent —> Workstation disconnected 


Figure 11. Watchdog Timetable for a Connection that Does Not Respond 


knowledgments Sent counter within 
the FCONSOLE Statistics-LAN I/O 
Statistics screen.) 

When the shell receives this reply 
from the server, it resets its timeout 
to zero and waits for the request. If 
the shell’s timeout expires again, it 
sends a third copy of the request just 
in case the response was lost in tran¬ 
sit from the server. This process con¬ 
tinues until the shell finally receives 
a completed response. 

Connection-Level Error 
Checking 

The connection between a worksta¬ 
tion and server can be lost due to a 
power failure or a communications 
problem. Both the file server and the 
workstation shell is equipped to han¬ 
dle this eventuality. At the worksta¬ 
tion, the connection is checked each 
time a request is made. If the shell 
does not receive a response to a re¬ 
quest after it retries a certain number 
of times (as dictated by the IPX Re¬ 
try Count), the shell assumes a con¬ 
nection problem and displays a 
message for the user. At this point, 
the user can either order the shell to 
resubmit the request or abort the 
operation completely. 


If the operation is aborted, the shell 
removes that connection from its 
Connection table. If it has no other 
server connections, the shell at¬ 
tempts to create a new connection 
with a server (using the initial con¬ 
nection sequence outlined in Figure 
3). If this attempt fails, the shell in¬ 
forms the user with the following 
message: You ore not connected to 
any file servers. The shell will try to 
connect to a file server whenever the 
current default drive is changed to 
an invalid drive. <Current drive is 
no longer valid>. 

At a NetWare file server, connection- 
level error checking occurs via ad¬ 
dress verification and periodic 
watchdog polling. When a file serv¬ 
er receives a request packet for a cer¬ 
tain connection, it verifies that the 
IPX source address within the re¬ 
quest packet matches the address re¬ 
corded for that connection in its 
connection table. If the addresses do 
not match, the server sends a re¬ 
sponse indicating that the connection 
number and address do not match. 

The Watchdog Process 

When a workstation is turned off, 
regardless of whether the user issued 
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the LOGOUT command first, the sta¬ 
tion’s connection remains occupied 
at the server. To clear these unused 
connections, the server uses the 
watchdog process to poll any clients 
the server hasn’t heard from in the 
last five minutes. The server tracks 
the time for each connection in the 
Watchdog Timer field of the 
server’s connection table. If the shell 
being polled is still operational, it 
responds to the watchdog query, and 
the server resets its timer for that 
connection. 

However, if the workstation has 
been turned off, or if there is a com¬ 
munications problem on the net¬ 
work, the server will receive no 
response from the shell. The watch¬ 
dog process then resets the connec¬ 
tion’s Watchdog Timer field to zero, 
but increments the Watchdog 
Counter field by one. The watchdog 
process sends another query to the 
workstation a minute later. As long 
as the watchdog continues to hear 
nothing from the workstation, it 
sends a packet every minute until it 
has sent a total of 11 polling packets 
to that workstation. The server 
clears the workstation’s connection 
if it receives no response to the last 
watchdog packet. 


NetWare version 
3.x-based servers provide 
a setable parameter that 
allows administrators to 
monitor when 
workstations are logged 
out by the watchdog 
process. 


Figure 11 illustrates the timetable 
for a connection that does not an¬ 
swer a server’s queries. NetWare ver¬ 
sion 3.x-based servers provide a 
setable parameter that allows admin¬ 
istrators to monitor when worksta¬ 
tions are logged out by the 
watchdog process. This option is set 
with the following command: SET 
CONSOLE DISPLAY WATCH¬ 
DOG LOGOUTS = ON. 


Conclusions 

A series of protocols governs 
NetWare’s client-server communica¬ 
tions. These protocols can be broken 
up by functionality: protocols used 
for all communications (the medium 
access protocols and IPX), adminis¬ 
trative protocols (the RIP and SAP), 
protocols concerned with connection 
control (the NCP and Watchdog), 
and, finally, the protocol that defines 
the coding of service requests (the 
NCP). 

This article has explained the opera¬ 
tion and interoperation of these pro¬ 
tocols; however, it makes no attempt 
to apply this information to all possi¬ 
ble network configurations and envi¬ 
ronments. It is up to network 
administrators to apply this informa¬ 
tion to their specific networks. 
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LANACS 

Protocols 

Mike Co luce i 
IBM Corporation 
Dallas , Texas 

Local Area Network Asynchro¬ 
nous Connection Server 
(LANACS) is a communications 
gateway. It makes available to 
LAN users a modem pool of up to 
32 asynchronous lines. This is a 
description of the LANACS envel¬ 
oping scheme in the token ring en¬ 
vironment. Understanding the 
frame formats and their envelop¬ 
ing scheme facilitates problem de¬ 
termination when using traces. 

In explaining the reasons why 
LANACS cannot communicate with 
other NetBIOS software, I normally 
use the following analogy: 

I have a PS/2 in Dallas on a LAN 
with a LANACS gateway. The 
LANACS gateway can dial a main¬ 
frame in Atlanta. If the mainframe is 
in a soft drink plant, and I have a 
spigot on my PS/2, why can’t I get 
the soft drink to flow from the plant 
to my spigot using LANACS as a 
gateway? 

The answer is that LANACS does 
not understand the interface called 
Soft Drink Transfer Interface 
(SDTI). It does understand ACSI 
and EBI. With the addition of OS/2 
EE ACDI redirection, it understands 
ACDI because ACDI is essentially 
the equivalent of EBI. Also, 
LANACS Version 2 includes 
TCP/IP support, so it understands 
the TELNET protocol of TCP/IP. 

So, LANACS is capable of speaking 
EBI, ACDI, ACSI, TCP/IP, and 
Async - but not SDTI. 


Let’s call the languages high-level 
frame formats. These high-level 
frame formats are enveloped in the 
lower-level frame formats, which are: 

• Media Access Control (MAC) 

• Logical Link Control (LLC) 

• NetBIOS 

Frame Formats from MAC 
Layer to LANACS 

The MAC-level frame is the lowest- 
level frame. It is what you see if you 
trace a token-ring. You might see a 
MAC-level abort frame, a MAC 
level frame used for LAN manage¬ 
ment, or a data frame that carries 
user data in an LLC frame. A MAC- 
level frame might also be a free-to¬ 
ken frame, but you won’t see it in a 
Trace and Performance (TAP) tool 
trace. 

The LLC frame is the next higher 
level frame. In the data portion of 
the LLC frame, you might have Net¬ 
BIOS, SNA, TCP/IP, and so forth. 

So from bottom to top, the MAC- 
level frame encapsulates the LLC 
frame. The LLC frame encapsulates 
the NetBIOS frame. The NetBIOS 
frame encapsulates the data. The 
data comes from LANACS and can 
consist of actual ASCII data. But it 
can also consist of non-ASCII data 
that LANACS can interpret. These 
are the interfaces mentioned in my 
soft drink analogy. 

MAC Frame 

As can be seen at the the bottom of 
Figure 1, there are several types of 
MAC frames. They all start with a 
bit pattern called a starting delimiter 
so the hardware can recognize the be¬ 
ginning of legitimate data. They all 
have an ending delimiter which is an¬ 
other particular bit pattern. That’s all 
there is to the abort frame. The free- 
token frame has an access control 


byte preceeding the ending delim¬ 
iter. And the MAC and data frames 
have a frame status byte following 
the ending delimiter. 

The MAC and data frames are simi¬ 
lar. Between the delimiters they 
have bytes for control, addressing, 
and data checking. The difference is 
that the MAC frame has a field for 
MAC-level commands and informa¬ 
tion and the data frame does not. 
Instead it has two fields. One is rout¬ 
ing information and the other is 
called the LLC Protocol Data Unit 
(LPDU). 

The important point here is that all 
the other fields surrounding the 
LPDU are the envelope provided by 
MAC-level software. That software, 
in this case, is on a token ring card. 
The protocol is named IEEE 802.5 
by the IEEE standards organization. 
The LPDU itself is the LLC frame 
encapsulated in MAC information. 

LLC Frame 

This frame contains the Service Ac¬ 
cess Point (SAP). 

When an application starts, it opens 
an SAP, which might be considered 
a type of address. When an applica¬ 
tion connects to another system it 
provides both its own SAP (source 
SAP) and the SAP of its partner (des¬ 
tination SAP). The communicating 
systems must use SAPs known to 
each other to communicate. For ex¬ 
ample, the NetBIOS SAP is F0. An 
SNA SAP is 04. Either one can ride 
in an LLC frame. A destination has 
to have SAP 04 open or the source 
can’t send it any 04 SAP informa¬ 
tion. It can’t talk to NetBIOS SAP. 

The control field in the LLC frame 
contains the LLC protocol, which 
consists of the commands and re¬ 
sponses. The rest of the frame is the 
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Abbreviations 

AC 

Access Control 

CONT Control 

DA 

Destination Address 

DSAP 

Destination SAP 

ED 

Ending Delimiter 

FC 

Frame Control 

FCS 

Frame Check Sequence 

FS 

Frame Status 

MAC 

Media Access Control 

LPDU 

LLC Protocol Data Unit 

LLC 

Logical Link Level 

SA 

Source Address 

SAP 

Service Access Point 

SD 

Starting Delimiter 

SSAP 

Source SAP 


Figure 1. IBM Token-Ring Protocols Used with LANACS (1 of 2) 
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o 

o 

o 
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Abbreviations 

ID Command ID 
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Figure 2. IBM Token-Ring Protocols Used with LANACS (2 of 2) 
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Abbreviations 

ARP Addr Resolution Prot 
CC Command Code 
CONT Control 
DSAP Destination SAP 
IAC Interpret as Command 
IP Internet Protocol 
LLC Logical Link Control 
ON Option Negotiation 
ORG Organization Type 
RARP Reverse ARP 
SAP Service Access Point 
SNAP Sub-NW Addr Prot 
SSAP Source SAP 


Commands 


End sub-negotiations 
No operation 
Data Mark 
Break Mark 
Interrupt process 
Abort output 
Are you there 
Erase character 
Erase line 
Go ahead 
Sub-negotiation 



Options 



TELNET Frame 
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Figure 3. TCP/IP TELNET Protocol Used with LANACS 
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data. This data field is the NetBIOS 
frame encapsulated in LLC informa¬ 
tion. The LLC protocol is named 
IEEE 802.2 and is also software that 
is found on the token ring card. 

NetBIOS Frame 

This frame starts with a field that de¬ 
fines the length of the header. Next 
is a 2-byte specific bit pattern that is 
the delimiter for the frame. The 
NetBIOS command follows. The 
command gives and takes all the in¬ 
formation it needs from a Network 
Control Block (NCB). The NCB var¬ 
ies depending on the command 
within it. The NetBIOS frame also 
contains source and destination infor¬ 
mation, just as the LLC and MAC 
frames. As each level is stripped off, 
the remainder has to have an address 
to go to until it reaches the applica¬ 
tion. Finally, following all this infor¬ 
mation in the NetBIOS header, is 
the data field. This data field is the 
LANACS data. 

Just as a reminder, NetBIOS stands 
for Network Basic Input/Output Sys¬ 
tem. The NetBIOS frame encapsu¬ 
lates the LANACS data frame. 
NetBIOS software is found in LAN 
Support Program. It is also part of 
OS/2 EE. It doesn’t have a name 
given by IEEE or any other organiza¬ 
tion because it is an industry defacto 
standard. 

LANACS Frame 

As can be seen from Figure 2, 
LANACS frames come in different 
forms, commonly called protocols. 
Actually, some are programming in¬ 
terfaces. (You'll find, although not 
accurate, the terms protocol and in¬ 
terface are often used interchange¬ 
ably. Put simply, interfaces are 
commands. Protocols are the se¬ 
quence in which the commands are 
used.) Figure 2 depicts both the 


ACSI protocol and the EBI protocol. 
ACDI uses the EBI protocol. 

ACSI: ACSI is a complicated lan¬ 
guage. It’s called a protocol in its 
original documentation in an issue 
of IBM Personal Computer Seminar 
Proceedings , Volume 3, #4, October 
1985 (G320-0323). Each command 
generates a series of NetBIOS com¬ 
mands. Sometimes, ACSI informa¬ 
tion or data is imbedded in a 
command, such as the data com¬ 
mand EFOB. 

EBI: EBI is a language written to 
PC interupt X’14’, which is the vec¬ 
tor that points to the async adapter 
device driver. When EBI is installed, 
the vector is changed to point to a 
LAN device driver so COM ports 
can be redirected to the LAN. Extra 
commands are added to the device 
driver. EBI commands generate ac¬ 
tions within the workstation or they 
generate NetBIOS packets that con¬ 
tain a command byte along with a 
data byte. Or it can generate a 
NetBIOS packet that contains ASCII 
data. This is unlike the ACSI data 
packet, in which a command vector 
precedes the ASCII data. The EBI 
NetBIOS packets (commands) are 
shown in Figure 2. 

In-depth information on EBI is 
found in the LANACS Installation 
and Configuration Guide. 

TCP/IP Frames 

Again, the protocol layers are encap¬ 
sulated in each other, as shown in 
Figure 3. 

The LLC Frame: The TCP/IP LLC 
frame is different than the NetBIOS 
LLC frame. The DSAP and SSAP 
fields contain hex ’AA’ (decimal 
’170’). That indicates that following 
the control field is a five-byte SNAP 
address. The control field is nor¬ 
mally followed by data. The ’AA’ 


also indicates that this is TCP/IP. 

The first three bytes of the SNAP ad¬ 
dress (the organization code field) 
have been assigned Os (zeros) by the 
standards committee. The next two 
bytes (type field) indicate which pro¬ 
tocol - IP, ARP, or RARP - is being 
used. If it is IP, the type field is hex 
’0800’ (decimal ’2048’). If it is 
ARP, the type field is hex ’0806’ 
(decimal ’2054’). And RARP has a 
type field of hex ’8035’ (decimal 
’32821’). 

The ARP Frame: This frame also 
has a SNAP indicator of hex 
’AAAA’. But the end of the frame 
contains actual TCP/IP addresses. In 
this case, the trace indicated a 
TCP/IP address of hex '09 13 8D 
05’ (9.19.141.05, the host address). 

The IP Frame: This frame is encap¬ 
sulated within the LLC frame as the 
data field. The IP header contains 
various information including 
addressing. 

The TCP Frame: This frame is en¬ 
capsulated within the IP frame as the 
data field. The TCP header contains 
port and control information. 

The TELNET Frame: TELNET 
commands are identified by hex 
’FF’ (decimal ’255’) in the first data 
byte. They are used to negotiate the 
bind parameters between the two 
communicating entities. That is one 
type of TELNET frame. The other 
type of TELNET frame is data. It 
does not contain the hex ’FF’ in the 
first byte. It can be straight data or 
3270 datastream data. If TN3270, 
which is supported by LANACS, is 
used, the data will be in 3270 da¬ 
tastream format. The TN in TN3270 
stands for TELNET, which is only 
one of many of a suite of protocols 
supported by TCP/IP. But remember 
that it is the only one supported by 
LANACS. 
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Composite Frames 

Finally, let’s put them all together in 
Figure 4 to see how it flows. 

(You will note that the SDTI is 
conspicuously absent.) 
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Figure 4. Local Area Network Protocols Used with LANACS 
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Random Data 


New Book: 

Client-Server 
Programming 
with OS/2 
Extended Edition 

This book on client-server comput¬ 
ing was written by Robert Orfali and 
Dan Harkey of IBM. Through easy- 
to-read, in-depth tutorials and work¬ 
ing code, the book shows how to 
integrate databases, LANs, and 
graphical front-end clients to build 
working client-server applications 
using OS/2 EE. A Club Med reserva¬ 
tion system serves as a grand finale 
that brings together GUI clients, 
database servers, and LAN 
communications. 

In addition to the tutorials, the book 
contains more than 300 pages of 
working code and benchmarks that 
demonstrate the many trade-offs in 
client-server design, such as: 


• Processes versus threads 

• APPC, NetBIOS, named pipes, or 
the LAN server 

• Static SQL versus dynamic SQL 

• Remote SQL versus stored 
procedures 

• Transaction servers versus data¬ 
base servers 

• GUI tools versus Presentation 
Manager programming 

The software in this book provides a 
jumpstart for creating OS/2 client- 
server applications in record time. 

To create a robust client-server plat¬ 
form, the authors use OS/2 EE’s ad¬ 
vanced features, including: 

• Referential integrity 

• Remote Data Services 

• Advanced peer-to-peer 
communications 

• Threads 

• Network and database administra¬ 
tion utilities 


The friendly style of this book ap¬ 
peals to a wide audience, ranging 
from novices to PC programmers 
and MIS professionals. It should 
also be of great interest to LAN and 
communications specialists, database 
administrators, and anyone inter¬ 
ested in SNA, SAA, or OS/2 EE. 

The book can also be used as a sup¬ 
plementary text for courses on net¬ 
works, operating systems, OLTP. 
LANs, SQL, database theory, ser¬ 
vers, and distributed systems. Final¬ 
ly, this book explains the power of 
OS/2 and how it fits with SAA and 
CUA. 

Authors: Robert Orfali and Dan 
Harkey 

IBM Mechanicsburg order nunber: 

G325-0650 

Description: 1000 pages, $39.95 
Publisher: Van Nostrand Reinhold , 
New York , New York 


IBM Personal Systems Developer 

The IBM Personal Systems Developer is a quarterly publication written primarily for OS/2 application program¬ 
mers. It features a variety of technical articles, such as programming tips and techniques, product reviews of new 
software tools, application development case studies, and interviews with OS/2 industry leaders. IBM employees, 
customers, and software vendors write articles for the Developer. The magazine is published as part of IBM's 
Developer Assistance Program, which offers a variety of support services for companies that are writing OS/2 
applications for resale. 

Subscriptions can be ordered be calling 1 800 READ-OS2. IBM employees can subscribe through 
Mechanicsburg’s Systems Library Subscription Service (SLSS), order number G362-0001. 
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Little Solutions 



Here are hints and tips from our readers. If you have “ little solutions '' to 
share , send them to us in care of the editor. 


Modifying Your LIBPATH 
Statement on the Fly 

A real problem for some OS/2 users 
is the inability to dynamically mod¬ 
ify the OS/2 library search path. 
While the PATH and DPATH state¬ 
ments can be modified easily, the 
LIBPATH statement is not part of 
the environment space and as such 
cannot be modified while OS/2 is 
executing. 

While this remains a hard-and-fast 
rule, here’s a trick you can use to 
gain a small measure of flexibility in 
your library path during execution. 


Code your LIBPATH statement with 
• 5 

as the first two characters on the pa¬ 
rameter line. This causes OS/2 to 
search the current subdirectory first 
before searching the libraries de¬ 
fined in the rest of the library path. 
By manipulating the current direc¬ 
tory, you can have some effect upon 
the library search path. 

Figure 1 is an example of the LIB¬ 
PATH statement with the current di¬ 
rectory defined as the first directory 
to search. - Dave Dill, IBM, Dallas 


Keystroke Savers 

Here are a few tips that will save 
many keystrokes when you’re work¬ 
ing in DOS. 

The first tip is a little-known feature 
of DOS that allows you to eliminate 
the use of asterisks as wildcard pa¬ 
rameters in conjunction with a DOS 
command (COPY, DEL, and so 
forth). DOS allows you to omit the 
asterisks so you can type: 

DEL . 

in place of 

DEL *.* 

For example, to copy all the files on 
your C drive root directory to a 
floppy disk you can type the 
command: 

COPY C:\. A: 

as opposed to 

COPY C:\*.* A: 

The next tip is a way to change from 
a subdirectory to a directory one 
level higher in your directory tree 
structure without specifying the 
directory name. For example, to 
change from the directory 
\BATCH\COMMANDS\UTILS to 
\BATCH\COMMANDS, you would 
normally type: 

CD \BATCH\COMMANDS 

To achieve the same result, you can 
simply type: 

CD. . 

The last tip is a way to use batch 
files that will save you from typing 
commands that have replaceable pa¬ 
rameters. For example, the program 
PKZIP (a widely used file compres¬ 
sion utility), along with its compan¬ 
ion program PKUNZIP allows you 
to compress many files into one 


LIBPATH=.; c: \1 i bra ry 1; c: \1 i bra ry 2; d: \1ibrary3; 


Figure 1. Example LIBPATH Statement 
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smaller file for easier portability be¬ 
tween DOS machines. After the file 
is transferred to the destination ma¬ 
chine, it can be decompressed back 
into its original form of many sepa¬ 
rate files. Let’s assume you want to 
back up all the files with the exten¬ 
sion .EXE in the directory \UTILS 
into one file called UTILS.ZIP. The 
command to do this (after making 
sure you are in the \UTILS direc¬ 
tory) is: 

PKZIP -A UTILS.ZIP *.EXE 

where -A tells it to add files to an ar¬ 
chive file, UTILS.ZIP is the output 
archive filename, and *.EXE is the 
range of files to include. You may 
then transfer the file to the destina¬ 
tion machine for decompressing. For 
the purposes of this example, let’s 
assume you put the file into the des¬ 
tination machine’s C drive root direc¬ 
tory and that you want the original 
decompressed files in a directory on 
the same drive called \TOOLS. The 
command to accomplish this is: 

PKUNZIP -X UTIL.ZIP \T00LS 

where -X tells it to extract files from 
the archive file, UTIL.ZIP is the in¬ 
put archive filename, and \TOOLS 
is the output directory name. 

Both of these commands are rather 
lengthy and cumbersome. Instead, 
simply create two simple batch files: 

The first batch file is called 
ZIP.BAT and compresses the files 
into an archive file. 

PKZIP -A %1 %2 

ex. ZIP UTILS.ZIP *.EXE 

The % 1 is a replaceable parameter 
whose value is determined by the 
first parameter after the name of the 
batch file ZIP; in the preceding ex¬ 
ample it is UTILS.ZIP. The %2 is 


also a replaceable parameter whose 
value is determined by the second 
parameter of the command. In our 
example it is *.EXE. 

The second batch file is called UN¬ 
ZIP. BAT and decompresses the ar¬ 
chive file back into separate files 
with the option of specifying which 
directory to put the files into. 

PKUNZIP -X %1 %2 

ex. UNZIP UTILS.ZIP \TOOLS 

The % 1 represents the input archive 
file name and %2 represents the out¬ 
put directory name. 

Make sure that these two batch files 
and the programs PKZIP.EXE and 
PKUNZIP.EXE are in directories 
that can be found in your DOS path 
(specified in your 
AUTOEXEC.BAT file). 

The files shown here are examples 
of the use of the % parameter. You 
may use the % parameter in your 
own batch files that start programs 
that have parameters that need to be 
input. 

These shortcuts can be real 
time-savers when used regularly. 

- Forrest York , Dallas 

LAN Solutions 

Out of Resources? Lan Server 1.3 
will fail to start if resources re¬ 
quested in the IBMLAN.INI file are 
larger than those defined in the Com¬ 
munications Manager configuration 
file. Lan Server 1.30.1 will allow the 
server to start, although the server 
will have fewer resources than re¬ 
quested. An error message, 

NET3198, will be written to the er¬ 
ror log to let you know all requested 
resources were not available when 
started. The error message does not 


say there was an error, it is just an 
informational message. 

Changes to Home Directories: 

Starting with LAN Server version 
1.30.1, home directories will no 
longer be defined as an alias. Also 
the home directories can be located 
on any server at any location on the 
server. 

Until version 1.30.1 of LAN Server 
(WR05015), when a home directory 
was created it was automatically put 
under the IBMLAN directory on the 
domain controller. Beginning with 
version 1.30.1, when the administra¬ 
tor is defining a home directory for 
a user, the system asks which server 
the home directory will be on and 
the path to the directory. If the path 
does not exist, the directory and path 
are created. This can also be done 
from the command line. Documenta¬ 
tion for this is on the README file 
for CSD 5015. 

When a home directory was created, 
an alias was automatically created 
and shared at user request with an 
access profile giving only that user 
access. With version 1.30.1, an alias 
is not created. The share will be a 
dynamic share just as you can do 
from the command line. There is a 
non-alias access profile created with 
only the user having access. 

Updating DLR from 1.2 to 1.3 
across the Network: There is no 
predefined function (as with the 
CSD download) that allows you to 
download DLR 1.3 to DLR 1.2 ma¬ 
chines. The options are to install the 
code on each diskette or to install 
the code on the server (because it is 
packed on the diskettes) and then 
copy it to an existing DLR worksta¬ 
tion. You could implement this func¬ 
tion by performing the following 
steps: 
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1. Install DLR 1.3 on one requester. 

2. Access a shared driver at the 
OS/2 1.3 Server from the 1 DLR 1.3 
requester. 

3. Copy the DOSLAN subdirectory 
tree structure to the server from the 
DLR 1.3 machine. 

4. Because the DLR 1.2 at 4098 ma¬ 
chines can log on to the OS/2 1.3 do¬ 
main, you can easily provide access 
to the files copied to the server in 
steps 2 and 3 to the DLR 1.2 at 
4098 machines. 

5. Copy the DOSLAN files from 
the server (that is, from steps 2 and 
3) to a new subdirectory at the DLR 
1.2 machines (that is, 
C:\DOSLAN13). Do not delete the 
original DLR 1.2 subdirectory until 
DLR 1.3 is working. 

6. Edit the DLR 1.2 
AUTOEXEC.BAT and change the 
PATH to C:\DOSLAN13 (or to 
wherever you copied the files). 

7. Edit the 

C:\DOSLAN13\DOSLAN.INI file 
(after you have copied it) to reflect a 
unique machine name. 

8. Reboot the DLR 1.2 machine. 
DLR 1.3 should then be available. 

DOS 5.00 and DLR: If you want to 
run DOS 5.00 and DOS LAN Re¬ 
quester, there are different proce¬ 
dures depending on what you 
currently have installed. 

DOS 3.3 and 4.01 users who have 
DLR installed can install the DOS 
5.00 Upgrade and then install the 
fixes provided with the Upgrade on 


the IBM Network diskette that is in¬ 
cluded. DLR must be installed be¬ 
fore the upgrade. If you try to install 
DLR 1.3 after the DOS 5.00 Up¬ 
grade, it will fail, displaying a mes¬ 
sage that you are out of storage. 

New DOS 5.00 users can install 
DOS 5.00, then install the DLR 
1.30.1 diskettes that are now being 
shipped with OS/2 LAN Server 
1.30.1. 

New DOS 5.00 users who have 
DLR 1.30 and CSD 5015 can use 
the following procedure if the server 
is at CSD WR05015: 

1. Install DOS 5.00. 

2. Edit CONFIG.SYS and make 
FILES=30. 

3. Install LAN Support Program 

4. Reboot the machine. 

5. On the first DLR 1.30 diskette, re¬ 
move the “read only” from the file 
CIP_MAIN.EXE (in the root 
directory). 

6. Copy CIP_MAIN.EXE from serv¬ 
er \IBMLAN\DOSLAN\NET to this 
diskette. 

7. Make the file CIP_MAIN.EXE 
“read only” on the diskette. 

8. Install DLR 1.30 on the 
workstation. 

9. Update base DLR files to 
WR05015 in the DOSLAN direc¬ 
tory. This may be done with the 
IBM DOS 5.00 Upgrade, or the user 
can copy the following files from 
the server \IBMLAN\DOSLAN\NET 


to a diskette: 

REDIR40.EXE 
NET.COM 
NETWORK.MSG 
NETWORK 1 .CMD 
NETWORK2.CMD 
NETWORK3.CMD 
Copy those same files to the 
DOSLAN directory on the worksta¬ 
tion using the following commands: 

attrib *.* -r 
copy a:\*.* c:\doslan 
attrib *.* +r 
attrib doslan.ini -r 

10. Start DLR, log on, and run 
INSTDLR.BAT (see CSD WR05015 
READ.ME) to update the rest of the 
workstation DLR files. 

NET WHO: If DLR users are 
dropped from NET WHO within one 
hour of logging on to the DLR, they 
need to add the /NMS:n (where n is 
one or more) in their DOSLAN.INI 
file. This uses a minimum of 2.7 K 
(4.4 K if HIMEM isn’t specified). 
They must also install fix IC02772, 
which is available from the software 
support center. 

Sharing CDROM: A CDROM can 
be successfully shared across the 
LAN using OS/2 LAN Server 1.2 or 
higher. The administrator must issue 
the following at the Server: 

NET SHARE cdrom=d:\ 

Issue at the OS/2 requester: 

NET USE D: \\servname\cdrom 

The administrator needs to create a 
non-alias access control profile for 
the path to the CDROM drive and 
give R access. 

- Monte Half IBM , Austin 
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New Products 

Hardware 

IBM PS/2 Model 70 386 
(081, 161, A81 and A16) 

These new PS/2 system units address a 
wide range of customer needs and en¬ 
hance the PS/2 family of systems with 
additional standard memory and en¬ 
hanced fixed disks. All of these models 
have 4 MB of standard memory and a 
32-bit microprocessor with the capability 
of supporting up to 16 MB of high-speed 
real memory. 

The 80386 processor models 081 (80 mil¬ 
lion bytes/20MHz), 161 (160 million 
bytes/20MHz), A81 (80 million 
bytes/25MHz) and A16 (160 million 
bytes/25MHz) enhance ESDI files and 
support the addition of an 80387 op¬ 
tional Math Co-Processor, which offers 
significantly improved system perform¬ 
ance for a desktop environment. The 
Models PS/2 70 386 8570-A81 and A16 
can be upgraded to the 25MHz i486 
processor by the installation of the 
486/25 Power Platform. 

These models are appropriate for ad¬ 
vanced users who perform numeric-inten¬ 
sive applications requiring floating-point 
operations, large processing intensive ap¬ 
plications or applications requiring high- 
performance fixed disks. These new 
models of the PS/2 70 386 family main¬ 
tain compatibility with most existing soft¬ 
ware products for IBM personal 
computers and systems. 

Highlights: 

• 32-bit 80386 (20MHz-25MHz) and 
large capacity 80 MB or 160 MB 
fixed disks with integrated controller 

• 4 MB memory on the system board 
and capacity of up to 8 MB high¬ 
speed memory on system board 

• Micro Channel ® architecture with 
one 16-bit and two 32-bit slot and op¬ 
tional 80387 Math Co-Processor 

Letter# 191-079, June 11, 1991 


IBM PS/2 Model 55 SX and 
Memory Upgrade for IBM 
PS/2 Model 55 LS 

New models of the PS/2 Model 55 SX 
(8555-041, 081) have additional standard 
memory, higher capacity and enhanced 
performance fixed disks. 

The PS/2 55 SX new models have 4 MB 
standard memory, a 32-bit microproces¬ 
sor with the capability of supporting up 
to 16 MB of system memory and a 40- 
million-byte or 80-million-byte fixed 
disk drive. 

Additional functions of the PS/2 Model 
55 SX include: 1.44 MB, 3.5-inch disk¬ 
ette drive; ports (keyboard, pointing de¬ 
vice, serial/asynchronous, parallel, 

VGA); three I/O slots and keyboard. 

Standard memory for the 32-bit micro¬ 
processor PS/2 Model 55 LS (8555-LE0 
and LT0) is increased to 4 MB with the 
capability of supporting up to 16 MB of 
memory. The 8555-LE0 and 8555-LT0 
can also be upgraded with a 40 MB or 
80 MB fixed-disk drive. 

Highlights: 

• New PS/2 Models 8555-041 and 081 
with fixed disks larger and faster than 
previous Model 55s; 4 MB standard 
memory; 80386SX 16MHz processor 

• Upgrade of PS/2 Models 8555-LE0 
and 8555-LT0 to 4 MB standard mem¬ 
ory; 80386SX 16MHz processor 

Letter# 191-077, June 11, 1991 

IBM PS/2 Model 40 SX 
(8540-040, 043, 045) 

The PS/2 Model 40 SX system unit util¬ 
izes the 80386SX microprocessor operat¬ 
ing at 20MHz with zero to two wait 
states to system memory. The Model 40 
SX ships with 2 MB (million bytes) sys¬ 
tem board memory (expandable to 16 
MB on planar), new 3.5-inch DASD op¬ 
tions, five slots and four bays, and 16-bit 
video graphics array (VGA). The 
80386SX microprocessor PS/2 Model 40 
SX has the following integrated func¬ 
tions: parallel port, serial port, pointing 
device port, VGA port, keyboard port, 


1.44MB diskette drive support. Math Co- 
Processor socket, and three single in-line 
memory module (SIMM) sockets (two 
available for memory expansion). The 
PS/2 Model 40 SX is offered in a disk¬ 
ette-only model (8540-040) and 40MB 
and 80MB fixed-disk models (8540-043 
and 8540-045). 

The Model 40 SX supports the IBM En¬ 
hanced (101-key) Keyboard, Space Sav¬ 
ing (84-key) Keyboard, or the IBM Host 
Connected (122-key) Keyboard. The key¬ 
board selection can only be specified in 
new equipment orders and cannot be or¬ 
dered separately for on-order or installed 
equipment. 

Also announced are two new 8 MB 
memory module options designed to ex¬ 
pand system board memory. The IBM 
PS/2 8 MB Memory Module Kit-80ns 
(#1401, 6450129) contains 8 MB of 80 
nanosecond memory on a single SIMM. 
The IBM PS/2 8 MB Memory Module 
Kit-70ns (#5116, 6450130) contains 8 
MB of high speed, 70 nanosecond mem¬ 
ory on a single SIMM. These memory 
module kits are supported on PS/2 Mod¬ 
els 35 SX, 35 LS, 40 SX, 57 SX, 90 XP 
and 95 XP. The PS/2 Models 90 XP and 
95 XP can now support up to 64 MB of 
memory on the system board. 

Letter# 191-076, June 11, 1991 

IBM PS/2 Model 35 SX 
(8535-040, 043) IBM PS/2 
Model 35 LS (8535-24X) 

The PS/2 Model 35 SX utilizes the 
80386SX microprocessor operating at 
20MHz with zero to two wait states and 
has the following integrated functions: 
parallel port, serial port, pointing device 
port, video graphics array (VGA 16-bit) 
port, keyboard port, 1.44 MB (million 
bytes) diskette drive support, Math Co- 
Processor socket, and three single in-line 
memory module (SIMM) sockets (two 
available for memory expansion). The 
PS/2 Model 35 SX is a 3-slot 2-bay sys¬ 
tem and is offered in diskette-only (040) 
and a 40MB fixed-disk model (043). AH 
models have 2 MB of memory standard 
on the system board (expandable to 16 
MB). The PS/2 Model 35 LS provides a 
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small footprint and low priced, general 
business solution. 

The Model 35 LS provides a local area 
network (LAN) workstation solution and 
is available with all the standard features 
of the Model 35 SX, with the following 
exception: no DASD devices are in¬ 
stalled in this “medialess” system, but a 
16/4 Token-Ring adapter with RIPL oc¬ 
cupies one of the three adapter slots. The 
PS/2 Model 35 SX is fully upgradeable 
to the Model 35 SX configurations. 

Both the PS/2 Model 35 SX and 35 LS 
support the IBM Enhanced Keyboard 
(101/102 keys), Space Saving Keyboard 
(84/85 keys) or the IBM Host Connected 
Keyboard (122 keys). The keyboard se¬ 
lection can only be specified in new 
equipment orders and cannot be ordered 
separately for on-order or installed 
equipment. 

The PS/2 Floor Stand is a new option 
available to customers who wish to in¬ 
stall the system unit in a vertical 
orientation. 

Letter# 191-075, June 11, 1991 

IBM Select-a-Keyboard and 
IBM PS/2 Host Connected 
Keyboard 

Select-a-Keyboard allows a customer to 
specify one of the PS/2 keyboards in this 
announcement for the initial orders of 
either the PS/2 Models 35 SX and LS, 
Model 40 SX or Model 57 SX. Those 
available are the Space Saving Key¬ 
board, the Enhanced Keyboard and the 
new Host Connected Keyboard. They 
are available in a variety of languages. 

The new Host Connected Keyboard will 
allow users to operate in both PC and 
Host modes from a PS/2, when used 
with either the IBM Personal Communi¬ 
cations/3270 Version 2.0 or the IBM PC 
3270 Emulation Program, Entry Level 
Version 2.0 products. This keyboard pro¬ 
vides a key arrangement very similar to 
that found on the most popular 3270 
style keyboard. Key caps are clearly 
marked for both 3270 emulation and 
PS/2 application usage. 

Letter# 191-086, June 11, 1991 


IBM PS/2 3.5-Inch 
Rewritable Optical Drive, 

128 MB Rewritable Optical 
Cartridge, Optical Drive 
Kit A 

The PS/2 3.5-Inch Rewritable Optical 
Drive (#0162, 6450162) is a new techno¬ 
logically advanced SCSI storage device. 
This attractively priced optical drive fea¬ 
tures high performance (4.3 MB per sec¬ 
ond data transfer rate, 66ms average 
seek time) and high capacity (127 mil¬ 
lion bytes) in a compact 3.5-inch half- 
high package. The drive accepts either a 
single-sided removable 3.5-inch magneto¬ 
optical (MO) cartridge that can be writ¬ 
ten and read many times, or a 3.5-inch 
optical read only memory (O-ROM). 

The drive adheres to the ANSI industry 
standard Small Computer System Inter¬ 
face (SCSI) X3.131-1986 and can be in¬ 
stalled in PS/2 Models 57 SX, 60, 65 
SX, 80, 90 XP, 95 XP, 3510 and 3511. 
When combined with either of the PS/2 
SCSI enclosures (3510-0V0, 3511-003), 
this versatile drive offers optical function 
to any PS/2 Micro Channel desktop or 
floor-standing system with a PS/2 SCSI 
adapter installed. 

The IBM PS/2 128 MB Rewritable Opti¬ 
cal Cartridge (38F8645 single pack, 
38F8646 five pack) is a 3.5-inch MO me¬ 
dia, similar in appearance to 3.5-inch 
diskette media. This media has a format¬ 
ted capacity of up to 127 million bytes 
and can be written and read many times. 
These attributes allow this media to be 
used for online/off-line data storage, 
backup/restore, software distribution, or 
a wide variety of data transfer 
applications. 

O-ROM is 3.5-inch optical read-only 
memory with up to 122 million bytes 
typical capacity, similar in appearance to 
3.5-inch diskette media. This media can 
be used by software or application devel¬ 
opers to distribute CD-ROM like applica¬ 
tions, such as data bases, encyclopedias 
and image books. 

The IBM PS/2 Optical Drive Kit A 
(#1121, 6451126) is specifically de¬ 
signed and required to support the instal¬ 
lation of a PS/2 3.5-Inch Rewritable 


Optical Drive (#0162, 6450162) in PS/2 
Models 60 and 80-041, 071, 111 and 
311 with either PS/2 Micro Channel 
SCSI adapter installed. 

Letter# 191-082, June 11, 1991 

IBM PS/2 2.3 GB External 
SCSI Tape Drive 

The family of PS/2 Small Computer Sys¬ 
tem Interface (SCSI) storage options is 
enhanced through the introduction of the 
IBM PS/2 2.3GB External SCSI Tape 
Drive (3532-023). This self-contained ex¬ 
ternal SCSI tape drive has the flexibility 
to be attached to any PS/2 Micro Chan¬ 
nel system equipped with either a PS/2 
Micro Channel SCSI Adapter or a PS/2 
Micro Channel SCSI Adapter with 
Cache. The 3532 is a high performance, 
large capacity, tape drive that has an in¬ 
stantaneous data transfer rate of 245 KB 
per second and can store up to 2.3 GB of 
data on one 8mm tape cartridge. Device 
reliability is enhanced through the use of 
a powerful Error Correction Code (ECC) 
function. 

Also being announced with the IBM 
PS/2 2.3GB External SCSI Tape Drive 
are two new SCSI cables that are unique 
to this device. The IBM SCSI Control¬ 
ler Cable (#2830, 31F4187) is required 
to attach the 3532 to the PS/2 system 
unit (via the external port of the SCSI 
adapter). The SCSI Device-to-Device Ca¬ 
ble (#3131, 31F4186) is required to at¬ 
tach the 3532 to another 3532, or to 
other SCSI devices already present. If 
other SCSI devices are to be added in a 
“daisy-chain” fashion, consult the appro¬ 
priate device information for cabling re¬ 
quirements. Either the Sytos Plus® OS/2 
(15F7193) or Sytos Plus/IBM DOS 
(15F7194) File Backup Utility is re¬ 
quired for operation. These utilities, 
when used with the 3532-023, provide a 
high-performance, large capacity, easy- 
to-use tape backup/restore system. Sup¬ 
port in the Novell environment is 
provided by Cheyenne Software, Inc. 
with their ARCserve® program. 

Letter# 191-085, June 11, 1991 
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IBM PS/2 2.88 MB 
DISKETTE DRIVE 

The PS/2 2.88 MB Diskette Drive is a 
3.5-inch one-inch high diskette drive that 
features media sense capability, and up 
to 2.88 MB of formatted capacity when 
a 3.5-inch 4 MB diskette is installed. In 
addition, this drive maintains read/write 
compatibility with 720 KB and 1.44 MB 
diskette drives. The drive is designed to 
be installed in either PS/2 Models 35 SX 
and LS, 40 SX, or 57 SX. 

Letter# 191-083, June 11, 1991 

IBM PS/2 1.44 MB Diskette 
Drive, 5.25-Inch External 
Diskette Drive Adapter 
Cable, and Selected 
Upgrade Kits 

The PS/2 1.44 MB Diskette Drive 
(#0030, 6451130) is a new option for the 
PS/2 Models 35 SX, LS, 40 SX and 57 
SX. This 3.5-inch one-inch high form 
factor diskette drive features up to 1.44 
MB of formatted capacity, read/write 
compatibility with 720 MB formatted 
diskettes and media sense capability. 

The IBM PS/2 5.25-Inch External Disk¬ 
ette Drive Adapter Cable (#1124, 

6451124) is required to attach a PS/2 
5.25-Inch External Diskette Drive to a 
PS/2 Model 35 SX, LS or 40 SX. This 
cable is installed internally and attaches 
the 5.25-inch adapter to the system unit 
diskette drive cable. 

The IBM PS/2 Upgrade Kit for Diskette 
Drives (#5106, 6451127) provides the ca¬ 
pability to upgrade a PS/2 Model 35 LS 
to accept either a 3.5-inch or 5.25-inch 
diskette drive. 

The IBM PS/2 Model 35 LS Upgrade 
Kit for Hardfiles (#5107, 6451128) pro¬ 
vides the capability to upgrade a PS/2 
Model 35 LS to accept either a PS/2 40 
MB Fixed Disk Drive (#1073, 6451073) 
or 80 MB Fixed Disk Drive (#1074, 
6451074). 

Letter# 191-084, June 11, 1991 


IBM PS/2 Internal Tape 
Backup Program Version 
2.0 (DOS compatible) 
and IBM PS/2 Internal Tape 
Backup Program Version 
1.01 (OS/2 
compatible) 

These backup programs enhance the 
PS/2 8540, 8550, 8560, 8565, 8570, 
8580, 8590 and 8595 by allowing the 
user to transfer up to 120 MB of format¬ 
ted data from a disk storage device to a 
removable mini-tape cartridge for later 
recall. 

For the customer’s convenience, the 
IBM PS/2 Internal Tape Backup Pro¬ 
gram Version 2.0 (DOS compatible) and 
the IBM PS/2 Internal Tape Backup Pro¬ 
gram Version 1.01 (OS/2 compatible) 
are also offered in separate convenience 
kits that include the appropriate program, 
the IBM PS/2 Internal Tape Backup Unit 
(#5279) and a formatted mini-tape car¬ 
tridge in one package. These backup pro¬ 
grams, when used with the IBM PS/2 
Internal Tape Backup Unit, provide the 
customer with an easy-to-use, easy-to-in- 
stall and technologically advanced inter¬ 
nal tape backup system. 

Upgrades from the earlier versions of the 
DOS compatible program to the IBM 
PS/2 Internal Tape Backup Program Ver¬ 
sion 2.0 (DOS compatible) or to the 
IBM PS/2 Internal Tape Backup Pro¬ 
gram Version 1.01 (OS/2 compatible) 
can be done by ordering the appropriate 
upgrade. Customers can upgrade from 
earlier versions of the OS/2 compatible 
program by ordering the IBM PS/2 Inter¬ 
nal Tape Backup Program Version 1.01 
(OS/2 compatible) upgrade. 

Letter #291-278, June 11, 1991 

IBM ISDN Interface 
Coprocessor 

The IBM ISDN Interface Coprocessor 
provides attachment to the Integrated 
Services Digital Network Basic Rate In¬ 
terface (ISDN BRI) and, when operating 
with supporting IBM software, provides 
the capability of full duplex data trans¬ 
mission by utilizing the two 64 kilobits 


per second (Kbps) information (B) chan¬ 
nels controlled by the 16 Kbps control 
(D) channel. 

The IBM ISDN Interface Coprocessor 
and supporting software, when installed 
in an AT® BUS PS/2 Model 30 (286), 
Model 35, or Model 40, enable ISDN 
connectivity not only to other similarly 
equipped PS/2 workstations, but also to 
Micro Channel Architecture PS/2 work¬ 
stations with the IBM ISDN Interface 
Coprocessor/2 Model 2 installed, IBM 
7820 ISDN Terminal Adapters, IBM 
3174 ISDN Basic Rate Interface Adapt¬ 
ers, and an AS/400 system with the BRI 
Adapter feature. 

Letter# 191-115, July 9, 1991 

IBM PS/2 486/50 Processor 
Upgrade Option 

The PS/2 486/50 Processor Upgrade Op¬ 
tion enhances the PS/2 Model 90 XP 
486 and 95 XP 486 family of systems. 
The processor upgrade option features 
the new Intel 80486 50MHz microproces¬ 
sor and provides the capability of proces¬ 
sor performance upgrade on the PS/2 
Model 90 XP 486 and 95 XP 486 sys¬ 
tems. This new microprocessor includes 
an internal memory cache controller, 8 
KB memory cache and an integrated 
floating-point processor unit. Addition¬ 
ally, an external 256 KB level two cache 
is provided as standard on the processor 
complex. The 486/50 Processor Upgrade 
Option significantly increases system 
processor performance in compute-inten¬ 
sive applications while providing invest¬ 
ment protection. 

Letter# 191-096, June 11, 1991 

IBM PS/2 8504 
Monochrome Display 

The PS/2 8504 is a 12-inch multimode 
analog display. It uses a Flatter Squarer 
Tube (FST) for optimal front of screen 
performance. Low emissions, front con¬ 
trols, 300-degree swivel with tilt and re¬ 
duced footprint are leadership design 
characteristics. The PS/2 8504 Mono¬ 
chrome Display is suitable for the low- 
end, low-cost market, where color is not 
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exploited, but high clarity in text, graph¬ 
ics and images is required. 

The PS/2 8504 Monochrome Display is 
engineered to meet the recommendations 
for lower field emissions (VLMF). 

Letter# 191-080, June 11, 1991 

IBM PS/2 8516 Touch 
Display Model 001 

The PS/2 8516 Touch Display brings a 
new dimension of interactive operation 
to the PS/2 product line, and is intended 
for new application areas where touch is 
used for input and interaction. No over¬ 
lay is required for touch operation and, 
therefore, front-of-screen quality is main¬ 
tained. Touch input resolution is equiva¬ 
lent to the display resolution. The 
display supports XGA mode and all 
VGA modes and can be operated as a 
Personal System/2 8515 Color Display. 
When attaching to PS/2 systems with 
XGA graphics capability, 256 colors at a 
time may be selected. 

Device drivers are supplied with the dis¬ 
play that support the touch operation 
with the IBM Disk Operating System 
(DOS) or OS/2 Standard Edition or OS/2 
Extended Edition operating system. 

In response to emerging customer re¬ 
quests, the PS/2 8516 Touch Display 
meets VLMF (Very Low Magnetic 
Field), field emission recommendations 
for Scandinavia. 

Letter# 191-081, June 11, 1991 

IBM Personal Printer Series 
II Impact Printers (2380 
and 2381) 

The IBM Personal Printer Series II (PPS 
II) 2380 Printer is a narrow-carriage 9- 
wire impact printer. The IBM PPS II 
2381 Printer is a wide-carriage 9-wire im¬ 
pact printer. Both printers are designed 
for attachment to IBM Personal Comput¬ 
ers, IBM personal systems, and selected 
IBM displays and processors. Both are 
medium-usage printers, offering low-cost 
ownership and versatile paper handling 
with a speed of 320 characters per sec¬ 
ond (320 CPS) in FastDraft mode. 


The IBM PPS II 2380 and 2381 Printers 
are excellent choices for customers need¬ 
ing versatile forms-handling impact print¬ 
ers. The printers also offer a new 
user-friendly operator panel that can be 
easily operated by the printer user. 

Letter# 191-110, July 9, 1991 

IBM Personal Printer Series 
II 2390 and 2391 Impact 
Printers 

The IBM Personal Printer Series II (PPS 
II) 2390 is a narrow-carriage 24-wire im¬ 
pact printer; the IBM PPS II 2391 is a 
wide-carriage 24-wire impact printer. 

Both printers are designed for attach¬ 
ment to IBM Personal Computers, IBM 
personal systems, and selected IBM dis¬ 
plays and processors. Both are medium- 
usage printers, offering low-cost 
ownership and versatile paper-handling 
with speeds of up to 200 characters per 
second (CPS) in FastDraft mode and up 
to 60 CPS in Letter Quality mode. 

The IBM Personal Printer Series II 2390 
and 2391 are excellent choices for cus¬ 
tomers needing versatile paper-handling 
impact printers or entry-level, high-reso¬ 
lution desktop graphics printers. The 
printers also offer a new user-friendly op¬ 
erator panel that can be easily operated 
by the printer user. 

Letter# 191-129, August 20, 1991 

IBM PCradio Models 001, 
002, 003 

The IBM PCradio is a hand-held rugged 
unit that extends host services to the mo¬ 
bile work force via a variety of communi¬ 
cation alternatives in a DOS-based unit. 
All models provide: 

• A 5-10MHz 80C186 processor with 
power management system 

• Integrated Circuit (IC) memory card 
slot 

• CGA liquid crystal display 

• QWERTY keyboard, featuring imbed¬ 
ded numeric keypad 

• 2400 bps internal modem 

• Battery charger 


• Serial and parallel (via the breakout 
box features) ports for attaching exter¬ 
nal devices. 

IBM will offer these models of the PCra¬ 
dio, depending on communications re¬ 
quirements (radio, cellular or telephone 
line). It will be available on a special-bid 
basis, with general availability in the 
fourth quarter 1991. The PCradio has not 
been approved by the Federal Communi¬ 
cations Commission (FCC). It is not, and 
may not be, offered for sale or lease, or 
sold or leased until the approval of the 
FCC has been obtained. 

Letter# 191-126, August 13, 1991 

Software 

IBM System Performance 
Monitor/2 Version 1.0 

IBM System Performance Monitor/2 
(SPM/2) Version 1.0 consists of an inte¬ 
grated package of performance monitor¬ 
ing and analyzing facilities executable in 
OS/2 SE or EE Version 1.2 or 1.3 envi¬ 
ronments. SPM/2 enables system admin¬ 
istrators to monitor system performance, 
analyze performance problems and use 
SPM/2 as an aid for performance tuning, 
load balancing and network growth man¬ 
aging efforts. In addition, SPM/2 enables 
application developers to verify perform¬ 
ance objectives and fine-tune 
applications. 

Highlights: 

• A Data Collection Facility that col¬ 
lects critical OS/2 CPU, disk and 
memory utilization data, enabling lo¬ 
cal or remote systems management 

• A Monitor Facility that enables real¬ 
time performance monitoring 

• Log and Report Facilities that unveil 
details of resource utilization on a dis¬ 
patched process basis 

• Memory and Directory Analyzers that 
enable in-depth analysis of OS/2 mem¬ 
ory management and disk capacity 
information. 

Letter #291-273, June 11, 1991 
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When companies connect hundreds and thousands of PCs in a building, the triplen harmonic currents 
add to those of the other non-linear loads creating unexpected electrical problems, (page 4) 


Database Manager has extensive data integrity 
and protection features, (page 8) 


CM workstations can access gateways to System/370 architecture hosts, 
other hosts supporting LU6.2 protocols, and ASCII hosts, (page 18) 


Aligning data structure can make significant performance 
improvements to an application, (page 25) 


Window panels can be created efficiently with 
the dialog box editor, (page 33) 


Compiling the application for introduction into the production environment is best 
done on the DOS machine after Micro Focus COBOL/2 has been installed, (page 51) 


Memory relief with DOS 5.0 can be 
quite dramatic, (page 54) 


The shell (NETx.COM) acts as the interface between user 
applications and NetWare file servers, (page 78) 


LANACS frames come in different forms, 
commonly called protocols, (page 93) 


Here’s a trick you can use to gain a small measure of flexibility 
in your library path during execution, (page 96) 
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